[FR] Local virtualvenvs + registering them / using them through `.python-version`

[real-yfprojects]

A local venv is one that doesn't sit in $(pyenv root)/versions but in an arbitrary location in my file system. I like to have one for each software project sitting in the same folder. This follows the principle of keeping related things together. However I do like the mechanism of configuring the venv with .python-version and storing it in a central directory. This doesn't work for all tools though:

Poetry, pipenv, ... create local virtualenvs using pyenv if configured that way. I would like to automatically activate them by setting the corresponding venv in .python-version.

Additionally, I would like to see a command for creating local venv with this tool (with pyenv).

Prerequisite

• [x] Make sure your problem is not listed in the common build problems.
• [x] Make sure no duplicated issue has already been reported in the pyenv-virtualenv issues. You should look in closed issues, too.
• [x] Make sure you are not asking us to help solving your specific issue.
  • GitHub issues is opened mainly for development purposes. If you want to ask someone to help solving your problem, go to some community site like Gitter, StackOverflow, etc.
• [x] Make sure your problem is not derived from packaging (e.g. Homebrew).
  • Please refer to the package documentation for the installation issues, etc.
• [x] Make sure your problem is not derived from other plugins.
  • This repository is maintaining the pyenv-virtualenv plugin only. Please refrain from reporting issues of other plugins here.

Description

• [x] Platform information (e.g. Ubuntu Linux 20.04): ubuntu 20.04
• [x] OS architecture (e.g. amd64):
• [x] pyenv version: 2.3.13
• [x] pyenv-virtualenv version: 1.2.1
• [x] Python version: >=3.7
• [x] virtualenv version (if installed): 20.14

[native-api]

https://github.com/doloopwhile/pyenv-register, linked from https://github.com/pyenv/pyenv/wiki/Plugins .

You can symlink environments to $PYENV_ROOT/versions (which is what that plugin does) just like installations.

[real-yfprojects]

Thank you very much. Sadly pyenv-register is no longer maintained.

(which is what that plugin does)

Looking at the source it creates a new virtualenv that uses system packages. This is not exactly what I am looking for.

You can symlink environments to $PYENV_ROOT/versions

This does work like a charm. I would still like to see this feature added to pyenv-virtualenv. It shouldn't be that hard to implement. I might even be able to write a PR.

[native-api]

Looking at the source it creates a new virtualenv that uses system packages. This is not exactly what I am looking for.

Wow. That's not what its description says! Okay, deleted from the wiki -- 'cuz what it actually does is not very useful.

This does work like a charm. I would still like to see this feature added to pyenv-virtualenv. It shouldn't be that hard to implement. I might even be able to write a PR.

Do you think it really belongs in Pyenv-Virutalenv? You can link anything, not just virtualenvs. Sounds like a prime use case for a Pyenv plugin.

In particular, you'd be more than welcome to make a real Pyenv-Register (or however you wish to name it)!

[real-yfprojects]

You can link anything, not just virtualenvs

What do you have mind that could be useful to link somewhere into $PYENV_ROOT?

In particular, you'd be more than welcome to make a real Pyenv-Register

You got me interested. This will allow me to improve my proficiency in bash scripting. What features would you find useful? I have these in mind:

• 'Register' a/all system installed python as system-X.x.x
• 'Register' python installations at arbitrary locations similarly.
• 'Register' venvs

(or however you wish to name it)!

Maybe I shouldn't name it the same to prevent name clashes. However I am not very creative when it comes to naming.

[native-api]

What do you have mind that could be useful to link somewhere into _$PYENVROOT?

Some other installations outside of the Pyenv ecosystem. Though with the prevalence of Pyenv, I have a hard time imagining many of those survived ;-) For one, Anaconda still make their own bundles.

Linking is a general-purpose mechanism. Someone may come up with something unorthodox!

You got me interested. This will allow me to improve my proficiency in bash scripting. What features would you find useful? I have these in mind:

* 'Register' a/all system installed python as `system-X.x.x`

Not sure how you're going to do this or why this would be needed. Note that system is special: in means whatever is further on PATH, regardless of where it's located. Though maybe you'll come up with something!

* 'Register' python installations at arbitrary locations similarly.

* 'Register' venvs

Start with whatever you yourself need. Then whoever finds your product useful will tell you what they need themselves!

Maybe I shouldn't name it the same to prevent name clashes. However I am not very creative when it comes to naming.

The usual boring-and-accurate vs exciting-and-confusing naming dichotomy :-)

[real-yfprojects]

Not sure how you're going to do this or why this would be needed. Note that system is special: in means whatever is further on PATH, regardless of where it's located.

I have python3.8 and python3.9 installed through my system package manager. It will always run the version first encountered on path. This is not always useful, i would imagine. Pydocstyle for example will always be sourced from one python only. The same applies for all other scripts.

I don't know yet how this could be implemented since installing pydocstyle with py3.9 will simply override the entry point of pydocstyle installed with py3.8. So how would one know what entry point to run for py3.8 if it does no longer exist...

boring-and-accurate

I prefer that for this case since I am not naming a new tool but a pyenv subcommand.

[real-yfprojects]

Any reasons against calling it pyenv-add exposing the pyenv add command?

[native-api]

Any reasons against calling it pyenv-add exposing the pyenv add command?

Sounds ambiguous to me. What does it "add"? A new version? And how would the opposite command the called -- remove? How is that different from uninstall?

My bikeshedding idea for a possible alternative name is "link" (and unlink). Kinda the most straightforward name possible. Not sure if unlink is needed -- maybe uninstall would suffice.

[real-yfprojects]

Sounds ambiguous to me. What does it "add"? A new version?

It adds venvs or other python installations by creating a symlink. I though about link too. It does match exactly what the tool does in the background, but doesn't describe the user facing meaning of the operation. It doesn't install/uninstalls anything but only adds existing installations.

[native-api]

I think UNIX users are sufficiently familiar with links to understand the term.

[native-api]

In any case, that's just my personal opinion since you asked for it :-)

[mrmeszaros]

Hey, anyone dared to create pyenv-link? Could You link to it?

[real-yfprojects]

Hey, anyone dared to create pyenv-link? Could You link to it?

Its on my TODO list however other projects cropped up.

[real-yfprojects]

I implemented such a link tool in https://github.com/real-yfprojects/pyenv-link/