Bug 1599422

I thought we had switched the guidelines a while ago to have unversioned binaries be Python 3. I know we've talked about it for years now... Did it really not change yet?

Unfortunately not. One of the (valid) arguments is that since python command is python2, unversioned commands should also be python2. With pip, I kinda get it, but there are other use cases, where I don't like it that much.

What about not shipping virtualenv at all, and telling people to use `python3 -m venv`?

We can decide not to ship virtualenv in the Python Classroom Lab. However where and how do we tell people to use venv?

(In reply to Petr Viktorin from comment #3)
> What about not shipping virtualenv at all, and telling people to use
> `python3 -m venv`?

FWIW that command doesn't seem to work across different Fedora spins. Here's an example on Silverblue:

$ python3 -m venv testing
Error: Command '['/tmp/testing/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.
$ python3 --version
Python 3.6.5

(In reply to Miro Hrončok from comment #4)
> We can decide not to ship virtualenv in the Python Classroom Lab. However
> where and how do we tell people to use venv?

To be fair I'm not sure if python3 -m venv meets all the requirements for virtualenv users or not. *IF* it does *AND* the community would like the move to using venv instead of virtualenv there are a few things that could be done:

- pythonX-virtualenv becomes a script which warns about the command being removed in favor of python3 -m venv. In the meantime it forwards to python3 -m venv $ARGS.
- python3 package is upadted with a virtualenv script which forwards to python3 -m venv $ARGS. python3 is updated to provide what the virtualenv package(s) provided.

$ python3 -m venv testing
Error: Command '['/tmp/testing/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.
$ python3 --version
Python 3.6.5

This should not happen if shipped form Fedora RPMs. I would consider it a bug.

(In reply to Miro Hrončok from comment #2)
> Unfortunately not. One of the (valid) arguments is that since python command
> is python2, unversioned commands should also be python2. With pip, I kinda
> get it, but there are other use cases, where I don't like it that much.

No one else is doing it this way. They're either fully versioned with alternatives managing the unversioned name (openSUSE, Debian), or they're only shipping the Python 3 version as the unversioned binary (OpenMandriva, Mageia, Fedora[ish]).

(In reply to Steve Milner from comment #5)
> To be fair I'm not sure if python3 -m venv meets all the requirements for
> virtualenv users or not. 

IMHO it does not. virtualenv works for older Pythons as well. It can run on new Python versions and let you decide what python version (or rather executable) you want to use inside the venv.

-m venv only works with newer versions and will always create a venv for the Python version (executable) that runs it.

Also, AFAIK virtualenv is used internally by other tools such as tox.

(In reply to Miro Hrončok from comment #4)
> We can decide not to ship virtualenv in the Python Classroom Lab. However
> where and how do we tell people to use venv?

It already is on the Fedora Developer Portal.
I guess there are no release notes specifically for Classroom, right?

(In reply to Steve Milner from comment #5)
> (In reply to Petr Viktorin from comment #3)
> > What about not shipping virtualenv at all, and telling people to use
> > `python3 -m venv`?
> 
> FWIW that command doesn't seem to work across different Fedora spins. Here's
> an example on Silverblue:
> 
> $ python3 -m venv testing
> Error: Command '['/tmp/testing/bin/python3', '-Im', 'ensurepip',
> '--upgrade', '--default-pip']' returned non-zero exit status 1.
> $ python3 --version
> Python 3.6.5

That's quite bad.
What's Silverblue and where do I file a bug for it?


> (In reply to Miro Hrončok from comment #4)
> > We can decide not to ship virtualenv in the Python Classroom Lab. However
> > where and how do we tell people to use venv?
> 
> To be fair I'm not sure if python3 -m venv meets all the requirements for
> virtualenv users or not. *IF* it does *AND* the community would like the
> move to using venv instead of virtualenv there are a few things that could
> be done:
> 
> - pythonX-virtualenv becomes a script which warns about the command being
> removed in favor of python3 -m venv. In the meantime it forwards to python3
> -m venv $ARGS.
> - python3 package is upadted with a virtualenv script which forwards to
> python3 -m venv $ARGS. python3 is updated to provide what the virtualenv
> package(s) provided.

When functionality moves from 3rd party packages to the standard library, it's usually cleaned up and simplified a bit. The virtualenv -> venv transition is no exception.
However, it does meet the vast majority of use cases.
The main thing that's different is the Python API.

(In reply to Petr Viktorin from comment #9) 
> That's quite bad.
> What's Silverblue and where do I file a bug for it?

"Silverblue is the new face of Fedora Atomic Workstation from Project Atomic. With good support for container-focused workflows, this variant of Fedora Workstation targets developer communities. If you want to emphasize that it is part of the Fedora project, calling it Fedora Silverblue is fine, too."

Site: https://teamsilverblue.org/
Issues: https://pagure.io/teamsilverblue/issues

Silverblue failure reported at https://pagure.io/teamsilverblue/issue/21 . It's an unrelated bug; please discuss it there.

OK. No more discussions. Should we go with option 2 then?

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

> 4) make /usr/bin/virtualenv a shell script that calls virtualenv-2 if available, virtualenv-3 if not, ship it from both subpackages (add explicit conflicts for smaller versions of the other subpackage)

Why not invert this? A shell script that calls virtualenv-3 if available. If it isn't, it falls back to the older virtualenv-2? I'd also be cool with using alternatives if people feel strongly about that.

I f we prefer virtualenv-3 we might as well go with option 2 and save ourselves some work and diverging upstream.

Then let's run with option 2. I'm a little worried about pushing people towards python 2 by default.

I can do this, but I'd rather get https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/4 merged first so I don't create conflicts.

https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/5

https://pagure.io/fedora-docs/release-notes/issue/212