On Fri, Mar 01, 2013 at 03:11:05AM -0500, Bohuslav Kabrda wrote:

----- Original Message -----

...

Dear list,

Django is a python based web-framework. The latest version 1.5 was released a few days ago, introducing compatibility to python 2 and python 3. It also carries one script to be installed into /usr/bin/django-admin,

The question here is now: How to handle that? Should that be the py2 version, py3 now, use an additional name for the py3 version? Using alternatives was also a proposal? -- Matthias Runge mrunge@matthias-runge.de mrunge@fedoraproject.org

I'd advise going with the standard solution that can be found in most of the other packages, e.g. py.test or nose. In django's case: django-admin-%{python2_version} # currently expands to "-2.7" django-admin-%{python3_version} # currently expands to "-3.3" django-admin # points to "-2.7" version When we switch to Python 3 as a default, we just flip django-admin to point to the 3.x version.

Actually.... it depends on the use case.

If one tool will operate on either code base then you only install one binary. This would be the case if django-admin can work with django apps written in python2 or python3. An example of this would be rst2html from python-docutils. The package maintainer can choose whether the python2 or the python3 version should be the installed version. Some criteria: level of upstream support for one or the other. Whether it's more likely that the user will have python2 or python3 installed on their system. At present, because yum is installed on everything we call Fedora you should likely use the python2 version unless upstream heavily favors the python3 versions of the tools.

OTOH, if the tool needs to use the same python interpreter as the code it's helping to manage then you need to be able to parallel install both versions. Bohuslav;s explanation is pretty much correct. The naming, however, should be python3-django-admin. The applications which name themselves Foo-2.7 and Foo-3.3 occur when upstream has adopted this naming convention. They are somewhat of a pain as when you use them in a spec file you need to use both the MAJOR and MINOR python version numbers (which, when the spec supports multiple fedora versions means you must ues %{python3_version}. By contrast, python3-foo can simply be hardcoded in as we don't support multiple python3 interpreters on a single release.

Without an actual django project to work against, I cannot tell which of these is the actual case here. Most of the subcommands of django-admin look like they could would work with either a python3 or a python2 django. But certain ones (shell) look like they might only work if the interpreter matches and others (sql, runserver) look as though it would depend on django-admin was coded.

Note that the python guidelines go into this issue quite extensively: https://fedoraproject.org/wiki/Packaging:Python#Executables_in_.2Fusr.2Fbin

-Toshio

On Fri, Mar 01, 2013 at 05:30:32AM -0500, Bohuslav Kabrda wrote:

----- Original Message -----

...

OTOH, if the tool needs to use the same python interpreter as the code it's helping to manage then you need to be able to parallel install both versions. Bohuslav;s explanation is pretty much correct. The naming, however, should be python3-django-admin. The applications which name themselves Foo-2.7 and Foo-3.3 occur when upstream has adopted this naming convention. They are somewhat of a pain as when you use them in a spec file you need to use both the MAJOR and MINOR python version numbers (which, when the spec supports multiple fedora versions means you must ues %{python3_version}. By contrast, python3-foo can simply be hardcoded in as we don't support multiple python3 interpreters on a single release.

Well, there is a slight problem here, I think. The first command that you usually run is django-admin startproject, which creates a project with manage.py script. Then it is standard (at least for me) to use just the manage.py script (works almost the same way as django-admin script). I think that this script should have a shebang containing the interpreter that django-admin was run with (e.g. run with python2, you will get python2 in shebang, same for python3). That would probably imply having both django-admin and python3-django-admin, right? The problem is, that this doesn't happen and the created manage.py always has just "python". I consider this to be a bug and I'll probably bring it up to upstream. What do you think?

Sounds reasonable. Upstream could also implement this as a command line switch like this:

django-admin --python3 vs django-admin --python2

But yeah, there should be some way to specify whether the project you're creating is meant to use python2 or python3.

-Toshio