make conda-forge requirements clearer
proppy opened this issue · 6 comments
Some of the packages currently requires conda-forge:
https://github.com/hdl/conda-eda/search?q=conda-forge&type=
Which might cause glibc issues when installed on top of regular anaconda base environment, see:
siliconcompiler/siliconcompiler#906 (comment) and https://conda-forge.org/docs/user/tipsandtricks.html#why-does-that-happen
Until we get rid of this hard dependencies (should we decide to do it), we should make clear that conda-forge is currently a hard requirements for those packages and advise that users bootstrap their environment with https://github.com/conda-forge/miniforge or by following the conda-forge getting started documentation:
https://conda-forge.org/docs/user/introduction.html#how-can-i-install-packages-from-conda-forge
/cc @mkkassem as I believe they were also hitting this issue when testing the packages.
another (non-exclusive) way to fix this is to submit said recipes (open_pdks, openroad, magic, netgen) for inclusion in conda-forge thru: https://github.com/conda-forge/staged-recipes, see https://conda-forge.org/docs/maintainer/adding_pkgs.html#adding-multiple-packages-at-once
another (non-exclusive) way to fix this is to submit said recipes (open_pdks, openroad, magic, netgen) for inclusion in conda-forge
exploring this here here: conda-forge/staged-recipes#18295
After chatting more with @mithro, I think we need both.
Conda EDA packages
- minimal
- don't depend on conda-forge
- designed for batch jobs and automation from cloud host
- auditable (easy to vendor and rebuild with all their dependencies from sources)
Conda Forge packages
- feature full
- depends on other conda-forge packages
- design for interactive and gui usage from multiple platforms (linux64, macosx, win)
- maintained as part of the conda-forge projects
Why not just move all the packages to conda-forge? They already have all the build infrastructure to make it easy to maintain the packages and make sure they are up-to-date. It would also eliminate any confusion about the need for the conda-forge channel since everything would come from conda-forge.
@curtisma I do agree that it would be nice to have all the conda-eda packages available in some form in conda-forge too as a long term goal.
conda-eda also include a fair amount of packages related to open source FPGA development (https://f4pga.org/), so this would requires a significant maintainance effort if we were to move everything (i.e: not only the open source silicon part).
So another way to look at what's proposed in #193 (comment) is an intermediate state to validate that the approach work for packaged related to open source silicon.