----- Original Message -----
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(a)matthias-runge.de>
> > <mrunge(a)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.
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?
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
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
--
Regards,
Bohuslav "Slavek" Kabrda.