an attempt to pack openfasoc like openlane with all dependencies

[saicharan0112]

Currently OpenFASoC extensively uses conda packages to install all dependencies as part of its installer script and docker images. This is an attempt to pack openfasoc so that it can be installed very easily along with all its dependency packages. But there are still a few more things to do to get the stable package that is built regularly, like below -

• use conda packages versions info that is stored in a file after the daily check (https://github.com/idea-fasoc/OpenFASOC/blob/main/conda_versions.txt). Need to investigate what changes that need to be done at OpenFASoC side.
• use requirements.txt file to install python libraries that are required for the generators. (https://github.com/idea-fasoc/OpenFASOC/blob/main/requirements.txt)

P.S - I took openlane files under /misc/openlane as reference to add files for OpenFASoC

@msaligane @proppy

[saicharan0112]

Please do share your suggestions on how to solve the two problems that I mentioned under points.

[proppy]

@saicharan0112 we're seeing issue with the CI #351, we need to fix those before reviewing this.

[saicharan0112]

@proppy Are there any packages that are built with very specific version of its dependent conda packages? I think because of conda config --set channel_priority strict, the build is failing to install specific versions of conda packages (see https://github.com/saicharan0112/conda-eda/actions/runs/6846441968/job/18613077303#step:3:1436). I know that this setting is a recommended ones but not sure if we can change it to flexible

Also I see that gdsfactory is not in this channel. I know that other pip packages are not available so I have no option but to leave them. However, @joamatab is it ok for you having gdsfactory distributed as a conda package too? If so, I can create one.

[proppy]

There is https://github.com/conda-forge/gdsfactory-feedstock, so another alternative would be to move the package to conda-forge (we had such loose plan with #198 and #193), happy to revisit them.

[saicharan0112]

There is https://github.com/conda-forge/gdsfactory-feedstock, so another alternative would be to move the package to conda-forge (we had such loose plan with #198 and #193), happy to revisit them.

Thanks, where do I need to mention to let the conda-build operation here know that it is present in conda-forge channel? Also is it possible to specify custom versions of conda packages in the metadata of the package?

About shifting to conda-forge, I am not sure if I can publish the package in conda-forge directly because it required a github release url whereas here I can just mention the github repo url and the branch, and cloning and checking out the branch is well taken here. TBH with conda-eda I see an advantage of getting the tool at the latest available commit (though this is built once in a day, I just need to wait for a single day to get the latest version, if updates are made)

[proppy]

Thanks, where do I need to mention to let the conda-build operation here know that it is present in conda-forge channel?

It's usually not a good idea to mix both, we would need to either bring other dependencies to conda-forge or bring gdsfactory here based on the existing recipe.

[proppy]

directly because it required a github release url

maybe openfasoc could do automated release similar to what verible is doing: https://github.com/chipsalliance/verible/releases ?

[proppy]

I just need to wait for a single day to get the latest version

conda-forge also has some automated way to bump version, see what's happening with magic here: conda-forge/magic-feedstock#101