Bug#752467: (no subject)

[Marvin Renich]

Control: tags -1 patch

[I'm now subscribed to this bug; no need to CC me.]

On Tue, 18 Nov 2014 01:59:18 +0200 Stefano Rivera  wrote:
> Hi Barry (2014.11.17_22:53:01_+0200)
> > The question still remains: how best to upgrade people who have
> > /usr/bin/virtualenv provided by python-virtualenv in Wheezy, so that they 
> > now
> > get /usr/bin/virtualenv provided by virtualenv in Jessie?  Using Recommends
> > was an attempt at that, but clearly it's not good enough.
> 
> Taking a step back, I think the only way to reliably do this is to have
> virtualenv be Python2 for jessie, and change it to Python 3 in stretch.
> 
> so:
> python-virtualenv Depends virtualenv
> virtualenv Depends python-virtualenv (ick a loop. Avoidable?)
> 
> and in stretch:
> virtualenv Depends python3-virtualenv
> 
> By then, anybody using virtualenv has had the virtualenv package
> installed.

I just ran into this issue.  I am installing OctoPrint from source on a
BeagleBone Black, and OctoPrint uses python2, and I would rather not
install python3 if I can avoid it.

My (strong) opinion is that the correct solution should involve a single
/usr/bin/virtualenv command that works correctly with both python2 and
python3.  I have attached such a script (only tested with python2) based
on Brian May's suggestion to use the trick from django-admin.

Once this is done, the dependencies sort themselves out very nicely:

python-virtualenv Recommends: virtualenv
python3-virtualenv Recommends: virtualenv
virtualenv Depends: python3-virtualenv (>= someversion) | python-virtualenv (>= 
someversion)

virtualenv should not depend on python or python3; this will happen
transitively from the python{,3}-virtualenv dependencies.

A Depends is the correct dependency in virtualenv, because it is useless
and doesn't function unless one of the modules is installed.

A Recommends is the correct dependency in python*-virtualenv because
either can by used as a python module without the virtualenv command,
but a user would normally have the command installed as well.

Anyone with a default apt configuration (i.e. installs Recommends by
default) will upgrade correctly.  Those (like me) who don't install
Recommends by default should be looking for new Recommends when
upgrading and should be able to handle the situation.

I believe that replacing the current /usr/bin/virtualenv with the
attached script and adjusting the dependencies as described above will
allow closing this bug, and I see no downsides.

...Marvin

#!/bin/sh
# EASY-INSTALL-ENTRY-SCRIPT: 'virtualenv==15.1.0','console_scripts','virtualenv'
shell_code=''' '
# shell code
if command -v python3 > /dev/null && test -e 
/usr/lib/python3/dist-packages/virtualenv.py
then
exec python3 "$0" "$@"
elif command -v python2.7 > /dev/null && test -e 
/usr/lib/python2.7/dist-packages/virtualenv.py
then
exec python2.7 "$0" "$@"
else
echo "Cannot find installed version of python-virtualenv or 
python3-virtualenv." >&2
exit 1
fi

python_code='''
# python code
# ONLY use DOUBLE quotes <"> after this line
__requires__ = "virtualenv==15.1.0"
import re
import sys
from pkg_resources import load_entry_point

if __name__ == "__main__":
sys.argv[0] = re.sub(r"(-script\.pyw?|\.exe)?$", "", sys.argv[0])
sys.exit(
load_entry_point("virtualenv==15.1.0", "console_scripts", 
"virtualenv")()
)

# End of Python code. Do not modify this line. #'

Bug#752467: (no subject)

[Barry Warsaw]

The weird package relationships are due to the interaction between historical
baggage, Debian Python policy, and the port of the cli to Python 3.

python-foo should only be for Python 2 compatible libraries, while python3-foo
is for the Python 3 compatible libraries.  Back when python-virtualenv (src
pkg) was the only thing available, it also contained /usr/bin/virtualenv, but
that won't work now that we want to provide both the Python 2 and 3 compatible
libraries.  Also, because /usr/bin/virtualenv is shebanged to python3, it also
doesn't make sense to include it in the python-virtualenv binary package.

The typical solution is to move the /usr/bin script (and manpage, etc.) into a
separate binary package, and it makes the most sense to call this
'virtualenv'.  Because /usr/bin/virtualenv is a Python 3 script, it Depends on
python3-virtualenv.  There are use cases for keeping python-virtualenv as a
separate Python 2-compatible library that would e.g. be importable.

The question still remains: how best to upgrade people who have
/usr/bin/virtualenv provided by python-virtualenv in Wheezy, so that they now
get /usr/bin/virtualenv provided by virtualenv in Jessie?  Using Recommends
was an attempt at that, but clearly it's not good enough.

Hopefully that explains most of the new arrangement.  The only questionable
dependency is the Recommends.  I'm not sure what better we can do.  We should
not add a Depends from python-virtualenv to virtualenv (and thus transitively
to python3-virtualenv) because then people might get a library they don't care
about (i.e. python-virtualenv).  virtualenv does Breaks/Replaces older
versions of python-virtualenv, but I guess that's not enough either.

I don't see how adding a Provides can help, unless we push an update to Wheezy
such that python-virtualenv `Provides: virtualenv`.  Would that work?  If not,
I don't really see any other package relationship declaration that we can use
to make this upgrade go more smoothly.  Suggestions welcome!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752467: [Python-modules-team] Bug#752467: (no subject)

[Brian May]

On 18 November 2014 07:53, Barry Warsaw ba...@debian.org wrote:

 The typical solution is to move the /usr/bin script (and manpage, etc.)
 into a
 separate binary package, and it makes the most sense to call this
 'virtualenv'.  Because /usr/bin/virtualenv is a Python 3 script, it
 Depends on
 python3-virtualenv.  There are use cases for keeping python-virtualenv as a
 separate Python 2-compatible library that would e.g. be importable.


For another solution, have a look at django-admin, provided by the
django-common package. You can call it using any of the following ways:

brian@aquitard:~$ django-admin# run as sh; autodetect python
brian@aquitard:~$ python2 /usr/bin/django-admin# force python 2
brian@aquitard:~$ python3 /usr/bin/django-admin# force python 3

That way it works if only python-django is installed and it also works if
only python3-django is installed.

The ability to force a particular version of python may not be so useful
for virtualenv however.
-- 
Brian May br...@microcomaustralia.com.au

Bug#752467: [Python-modules-team] Bug#752467: (no subject)

[Barry Warsaw]

On Nov 18, 2014, at 09:39 AM, Brian May wrote:

For another solution, have a look at django-admin, provided by the
django-common package. You can call it using any of the following ways:

brian@aquitard:~$ django-admin# run as sh; autodetect python

Yep, that autodetect is clever.  Such a thing does often come up.

brian@aquitard:~$ python2 /usr/bin/django-admin# force python 2
brian@aquitard:~$ python3 /usr/bin/django-admin# force python 3

If a script is shebanged with one Python version or another, this is always
possible.  I use it in fact to run /usr/bin/python-coverage with a
virtualenv'd python.

That way it works if only python-django is installed and it also works if
only python3-django is installed.

The ability to force a particular version of python may not be so useful
for virtualenv however.

I don't think it is, since you can still create virtualenvs of whatever Python
you want with the -p option, regardless of what the virtualenv script is
shebanged.

The problem here is how to specify the package dependencies such that someone
who only has python-virtualenv installed in Wheezy, would automatically get
virtualenv in Jessie, for the /usr/bin script.


signature.asc
Description: PGP signature

Bug#752467: (no subject)

[Stefano Rivera]

Hi Barry (2014.11.17_22:53:01_+0200)
 The question still remains: how best to upgrade people who have
 /usr/bin/virtualenv provided by python-virtualenv in Wheezy, so that they now
 get /usr/bin/virtualenv provided by virtualenv in Jessie?  Using Recommends
 was an attempt at that, but clearly it's not good enough.

Taking a step back, I think the only way to reliably do this is to have
virtualenv be Python2 for jessie, and change it to Python 3 in stretch.

so:
python-virtualenv Depends virtualenv
virtualenv Depends python-virtualenv (ick a loop. Avoidable?)

and in stretch:
virtualenv Depends python3-virtualenv

By then, anybody using virtualenv has had the virtualenv package
installed.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org