add support for named global environments

[kkontosis]

Hello, I've been using zpy as a package manager for myself, with some modifications to allow for creating and using named environments that are shared between projects (like in conda / virtualenv), so that the "venv" name is not a hash, but an actual name.

Sending this PR in case you like the modification and you think that's something you would like to be integrated in zpy.

Example of how I use it:

~/var/my-proj
❯ activate -i     ## manually select /Users/kimon/.local/share/venvs/g311

~/var/my-proj                                                                         (venv-g311) 2s
❯ which python
/Users/kimon/.local/share/venvs/g311/venv-g311/bin/python

~/var/my-proj                                                                         (venv-g311) 2s
❯ ...do project work here

... and in order to install shared libraries:

~/var/my-proj                                                                         (venv-g311)
❯ cd /Users/kimon/.local/share/venvs/g311

…/share/venvs/g311                                                                    (venv-g311)
❯ ls -l
total 24
lrwxr-xr-x   1 kimon  staff    36 Mar 12 16:19 project -> /Users/kimon/.local/share/venvs/g311
-rw-r--r--   1 kimon  staff  2858 Apr  5 03:30 requirements.in
-rw-r--r--   1 kimon  staff  5431 Apr  5 03:30 requirements.txt
drwxr-xr-x  12 kimon  staff   384 Mar 14 20:46 venv-g311

…/share/venvs/g311                                                                    (venv-g311)
❯ pipacs ...

[AndydeCleyre]

Thanks so much, for letting me know zpy's been useful, and for sharing your changes!

Sorry I haven't brought my full attention to this PR yet. I do want to understand what you're doing here, and start evaluating it by comparing it to the simplest approximation possible with the current state of zpy.

Is the following correct?

• You've made a special case for when what I call the "project" (folder with requirements files) is in $ZPY_VENVS_HOME (~/.local/share/venvs).
• In this case, the venv is a named venv in that folder.
• The advantages are:
  • Simple navigation to the the venv, as short names are used without hashes
  • External integrations show the venv name, and the named venv makes this more useful and communicative

[kkontosis]

Hello @AndydeCleyre ,
Your understanding of my PR is correct. To put the same in different words, and add some additional info:

• If a project folder is in $ZPY_VENVS_HOME it is treated it specially
• If the subfolder of $ZPY_VENVS_HOME is named foo the venv is also named venv-foo
• Also importantly, in that special case, no different hash folder is created. The project symlink links to its own parent folder. That way all files (requirements.txt, requirements.in, project, venv-foo) live in the same directory.

The original problem I was facing was: suppose I want to treat a python environment as "global", just like pip using conda / virtualenv. My limitation, using either uv directly, or zpy was that it would have to have a "path", instead of just a name. Using zpy was closer to achieving my goal but I'd still have to provide a full directory path somewhere, and consider that to be the "global" env, and in addition to that, it would also fragment its files between that directory and the hash directory, which doesn't allow the underlying "global" environment to be easily treated as a directory and duplicated / copied, the way it can be done with virtualenv.

So the suggested change is that, if the venv "path", is within the $ZPY_VENVS_HOME itself, it is considered a "global" env, and it doesn't need a separate directory: the hash and the directory are the same.

The advantages are the ones you mentioned:

• Simpler navigation, meaning I can find it using a name. I would not be able to remember the hash.
• External integrations show the venv name.
  And in addition:
• The entire directory contains the entire environment. E.g. if I duplicate it I get the same thing, (with just adjusting the project softlink manually or by just making it a relative soft-link to . initially, in that special case, as an improvement - could be added to the PR). I can treat it as a state of installed libraries. This useful feature also applies to virtualenv environments.
• This mechanism in zpy can be used as a in-between step for supporting named environments. E.g. I can easily create a shell alias function that does something like: activate-named-env foo and it actually calls $ZPY_VENVS_HOME/foo/venv-foo/bin/activate.

And essentially with this merged, the user can choose between having any of:

• per-project environment, sensitive to the current path / activation path
• globally applicable environment, shared among many projects
  at any given point.

If this logic is applied, there are improvements, like, e.g. currently, when running pipacs I have to cd to the "global" directory first, where ideally in that case I'd like it to know the special case, and automatically cd in order to apply the changes to the "global" requirements.in, requirements.txt file, but that's another issue since all that will anyway be doable with some manual work.