Pipx: Support for Python 2 virtualenvs

[schlamar]

Would you consider adding support for Python 2 virtualenvs if I'm contributing a PR?

There are various reasons for having that feature. E.g. packages which are Python 2 only (#65) or if you want to have something like flake8 for Python 2 and for Python 3 available.

This shouldn't be to hard:

• use virtualenv instead of venv in create_venv if Python 2 is the base Python
• fix get_binaries_script so it is 2/3 compatible
• add a --binary-suffix flag which is passed to expose_binaries_globally so you can install the same binary from multiple venvs (so maybe create a flake8-2.exe). To make upgrade work we have to store the suffix in a config file. But this might be an interesting feature even without Python 2 virtualenvs.

[cs01]

I appreciate the offer and would probably be open to it, but there is still the issue of not having pathlib installed, no f-strings, various subprocess incompatibilities and likely some encode/decode issues.

After those were fixed, then your changes could be added. But I am not interested in maintaining a codebase without those features 😞 . I suppose pipsi might work for this use case?

[pmav99]

@cs01 if you are OK with having version dependent dependencies, there are backports for subprocess and pathlib. There is even an f-string backport but to be honest, I would feel reluctant to use it on "production". Plain strings are not the end of the world after all.

That being said, even though upstream support for Python 2 ends at 2020, distributions vendors (e.g. Canonical/RedHat) might decide to continue supporting it for many more years. The end of line for Ubuntu 18.04 is 2028 after all. So, supporting Python 2 might be a long-term commitment.

[cs01]

Edit: I just realized that all of pipx's code does not have to support python2, just the subprocess calls (you already said this in your first issue too 😄 ). Because of this, I don't think any of the backports you talked about are necessary.

So in this case, I would be open to a PR from you. You can ignore what I wrote below. Installation of pipx would still have to be with Python 3.6+, but pipx could install packages w/ Python2 (it can already install Python3.3+) as long as it had virtualenv available.

---

Original:
There will be some cases where packages only have a Python implementation under 3.3 (the version in which venv was introduced), but they are in a minority (I think). In those cases, pipx will not be an option and virtualenv or a system install will have to be used instead. There are lots of tools moving to Python 3.6+ only, and I think this is a good thing because it forces people to get unstuck from old versions. So although I wish I could promise support for all environments, I have to make tough choices around my own sanity/support workload (I do this in my spare time) and which environments the tool is advertised to support.

[schlamar]

get_binaries_script is run in the venv so it must be Python 2/3 compatible. Actually, I don't like this style of having the script embedded as string (no source code checking possible, not really debuggable, etc.). What do you think about putting this in a real script and just passing arguments to it?

What do you think about --binary-suffix (I would really need this for my use case: two flake8 versions)? At first, we could ignore the config file / upgrade issue as upgrades are not reproducible anyhow (see other open issues).

[aiguofer]

I know these types of comments aren't that helpful, but I'd love to have the ability to do this to install geeknote through pipx

[cs01]

Actually, I don't like this style of having the script embedded as string (no source code checking possible, not really debuggable, etc.). What do you think about putting this in a real script and just passing arguments to it?

@schlamar I love this idea. I have been meaning to do this. pipsi does it.

What do you think about --binary-suffix (I would really need this for my use case: two flake8 versions)? At first, we could ignore the config file / upgrade issue as upgrades are not reproducible anyhow (see other open issues).

What would this do? Install to a different pipx venv?

I know these types of comments aren't that helpful, but I'd love to have the ability to do this to install geeknote through pipx

@aiguofer No way, I definitely appreciate it. Good to know the work won't go to waste.

[schlamar]

What would this do? Install to a different pipx venv?

No, this would just append a suffix to the binaries in expose_binaries_globally. There are scripts which behave different depending on the Python version they are installed with. E.g. flake8 does checking for Python 2 when installed on Python 2 and checking for Python 3 when installed on Python 3.

So my idea to get a flake8.exe for Python 3 and a flake8-2.exe for Python 2:

pipx install flake8  # default flake8.exe for Python 3
pipx install flake8-2 --binary-suffix -2 --python C:\Python27\python.exe --spec flake8  # installs flake8 with Python 2 as flake8-2.exe

[cs01]

Oh I see what you mean. That is a pretty cool idea. It would require pipx to change how it installs packages since pipx uses the folder name of the virtual environment to determine the package name. So pipx currently would not let you install a package of the same name with two different versions.

I am not sure this is something that belongs in pipx because it starts going into areas where I think there would not be very many users plus it would be hard to implement and maintain. You might be better off just manually creating a venv and a symlink at that point.

[schlamar]

It would require pipx to change how it installs packages

No, actually you can already install unrelated packages with the spec parameter (see my example call above). The only change would be passing the suffix to expose_binaries_globally and append it to the targets of copy/symlink operations.

[cs01]

Pipx has been modified to have its inline strings in a script like you mentioned. It will be easier to support python2 only packages if you want to give it a shot now.

[schlamar]

Thanks. This is definitely on my TODO list, but I'm kind of busy right now...

[stanislaw55]

Hi,
I would be very interested in having support in pipx for Python 2. Isolating old apps is in my opinion perfect use case for pipx.
Does anyone have some info about this feature?

[uranusjr]

You want to look at pipx.venv.Venv.create_venv(), and change the call to use virtualenv instead (and also provide the corresponding flags). Environments created by virtualenv 20.0+ are expected to be completely compatible with ones created by the standard library venv, and I expect the change to cause minimal impact.

Note that, however, since virtualenv carries a bunch of extra dependencies, it is unlikely a good idea to carry virtualenv as a hard dependency of pipx. I would try to do something like:

1. Try the virtualenv command, if available.
2. Use venv, if the Python version is 3.4 or later.
3. Generate an error message saying the user needs to pipx install "virtualenv>=20" for Python 2 support.

[itsayellow]

Since Python 2 is EOL, this isn't something we have the time or inclination to support in pipx.