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