----- 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@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.
>
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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/packaging
--
Regards,
Bohuslav "Slavek" Kabrda.
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
