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@xxxxxxxxxxxxxxxxx>
> > <mrunge@xxxxxxxxxxxxxxxxx>
>
> 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
Attachment:
pgpurFJQZZGmf.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
