You appear to be reinventing Conda / PyPi / FuseSoC / etc - consider just being a wrapper for existing ecosystems?

[mithro]

Reading the description of volare, it sounds like you are quickly starting to reinvent existing tooling like Conda / Pip / FuseSoC / etc. Your tool_metadata.yml file sounds a lot like Conda's environment.yml and Pip's requirements.txt. These existing systems have quite a large amount of tooling already written for them.

Have you considered making volare just a thin wrapper around these existing solutions (if it isn't already)?

I know that @olofk and @proppy where looking at this problem too. @umarcor, @kgugala and @carlosedp have been working on similar problems in the FPGA space.

[donn]

PIP has a 60 MB storage upload limit and has no inherent provision for switching between versions, but was in consideration.

Conda already has sky130 builds, and this tool is designed for condaless setups.

The tool_metadata.yml file is indeed similar, but not identical, as it is used in OpenLane and DFFRAM's build systems, which do not use conda. And is entirely nonconsequential to the existence of volare itself, as all volare does with tool_metadata.yml is provide a convenience function. Volare can be used independent of said manifest file.

This is a tool laser-focused on managing PDKs and switching between them quickly. Think of it more like a version manager along the lines of tj/n or pyenv for PDKs rather than a fully-fledged package manager.

[mithro]

pip can install from other locations than just PyPi -- see the options at https://pip.pypa.io/en/stable/cli/pip_install/#examples

[donn]

I'm aware. But the no multiple-version-management part stands.