make conda-forge requirements clearer

[proppy]

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

[proppy]

/cc @mkkassem as I believe they were also hitting this issue when testing the packages.

[proppy]

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

[proppy]

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

[proppy]

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

[curtisma]

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.

@proppy, @mithro

[proppy]

@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.