On Tue, 2020-06-23 at 15:51 -0700, David Mathog wrote:
What I am after is some method of keeping exactly one copy of each package-version in the common area (ie, one might find foo-1.2, foo-1.7, and foo-2.3 there), while also presenting only the one version of each (let's say foo-1.7) to a particular installed program. On linux it might do that by making soft links to the common PYTHONPATH area from another directory for which it sets PYTHONPATH for the application. Finally, this has to be usable by any account which has read execute access to the main directory.
Does such a beast exist? If so, please point me to it!
zc.buildout[1] and zc.recipe.egg[2] can do something very much like this. zc.buildout tries hard to maintain reproducibility and isolation, and one of the ways it does this is by keeping each package in its own .egg directory. It then generates the entry-point scripts and a REPL with ``sys.path`` explicitly set to reference exactly the versions specified. There's no virtualenv-like activation step that puts all those scripts on the path, though, so one must either do that manually or just invoke the generated scripts directly.
For example, here's a buildout configuration that specifies a shared directory to store eggs in. It also has some parts using zc.recipe.egg, one that will use zope.interface 4 and one that will use zope.interface 5 (egg specifications can be arbitrarily complex, of course, dependencies are followed, etc):
[buildout]
eggs-directory = /<path>/buildout-eggs
abi-tag-eggs = true
parts =
old-interface
new-interface
new-interface-plus
[old-interface]
recipe = zc.recipe.egg
eggs =
zope.interface == 4.0
interpreter = old-py
[new-interface]
recipe = zc.recipe.egg
eggs =
zope.interface == 5.1
interpreter = new-py
[new-interface-plus]
recipe = zc.recipe.egg
eggs =
zope.interface == 5.1
zope.component
interpreter = new-py-plus
After running `buildout`, I have three REPL files (if zope.interface had defined any entry point scripts, I could also have had those generated):
$ head bin/new-py
#!