/usr/bin/django-admin in python-django

Brian May

unread,

Jul 6, 2014, 10:00:03 PM7/6/14

to

While I am happy with the majority of this package, not sure about this wrapper. It was designed to prevent conflicts between python-django and python3-django.

As an example:

(wheezy)root@aquitard:~# /usr/bin/django-admin dumpdata --settings=karaage.tests.settings

Traceback (most recent call last):

File "/usr/lib/python2.7/dist-packages/django/bin/django-admin.py", line 5, in <module>

management.execute_from_command_line()

File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 399, in execute_from_command_line

utility.execute()

File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 392, in execute

self.fetch_command(subcommand).run_from_argv(self.argv)

File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 261, in fetch_command

commands = get_commands()

File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 107, in get_commands

apps = settings.INSTALLED_APPS

File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 54, in __getattr__

self._setup(name)

File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 49, in _setup

self._wrapped = Settings(settings_module)

File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 132, in __init__

% (self.SETTINGS_MODULE, e)

ImportError: Could not import settings 'karaage.tests.settings' (Is it on sys.path? Is there an import error in the settings file?): No module named tests.settings

The problem is that the django-admin wrapper chose the python3 version, but karaage.tests.settings is only available in Python2, even though I have python3-django installed.

However, anything I do here will mean making changes from upstream.

I guess I could also try to parse the --settings or DJANGO_SETTINGS_MODULE, try to determine automatically if the Python3 version exists. However I think this could get very messy very quickly and probably won't work in all cases.

This is significant for me, as I have postinst scripts that do the following:

django-admin collectstatic --settings=kgadmin.conf.settings --noinput

Have changed that now to:

python2.7 /usr/lib/python2.7/dist-packages/django/bin/django-admin.py \

collectstatic --settings=kgadmin.conf.settings --noinput

Can change it for new packages, not for old packages though. I don't see any good solution for this though.

Hopefully nobody else does this :-)

--
Brian May <br...@microcomaustralia.com.au>

Brian May

unread,

Jul 19, 2014, 9:20:01 PM7/19/14

to

On 7 July 2014 11:55, Brian May <br...@microcomaustralia.com.au> wrote:

The problem is that the django-admin wrapper chose the python3 version, but karaage.tests.settings is only available in Python2, even though I have python3-django installed.

See bugs #755341 and #755321.

Looks like code is trying to run django-admin as a python script, allows it to specify which version of python to use.

Only thing is, it isn't Python. It is now shell. This allows automatic choosing of which Python version to use.

Unfortunately, it might be more important being able to manually specify which Python version to use.

--
Brian May <br...@microcomaustralia.com.au>

Brian May

unread,

Jul 19, 2014, 9:50:01 PM7/19/14

to

On 20 July 2014 11:12, Brian May <br...@microcomaustralia.com.au> wrote:

See bugs #755341 and #755321.

Looks like code is trying to run django-admin as a python script, allows it to specify which version of python to use.

Only thing is, it isn't Python. It is now shell. This allows automatic choosing of which Python version to use.

Unfortunately, it might be more important being able to manually specify which Python version to use.

Or, another words, ideally we want all these to work:

python2 /usr/bin/django-admin - python2

python3 /usr/bin/django-admin - python3

/usr/bin/django-admin - autodetect.

Wonder if it is possible to have some magically hash bang line in /use/bin/django-admin to autodetect the python version to use? e.g.

=== cut ===

#!/usr/bin/python-auto-detect

from django.core import management

if __name__ == "__main__":

management.execute_from_command_line()

=== cut ===

--
Brian May <br...@microcomaustralia.com.au>

Jakub Wilk

unread,

Jul 20, 2014, 5:10:02 AM7/20/14

to

* Brian May <br...@microcomaustralia.com.au>, 2014-07-20, 11:47:

>Or, another words, ideally we want all these to work:
>
>python2 /usr/bin/django-admin - python2
>python3 /usr/bin/django-admin - python3
>/usr/bin/django-admin - autodetect.

One possibility is to write a shell script that is also valid Python
code. PoC:

#!/bin/sh
sh=''''
if command -v python3 > /dev/null; then
exec python3 "$0" "$@"
else
exec python "$0" "$@"
fi
' '''
import sys
print("I'm Python %d.%d!" % sys.version_info[:2])

Another possibility is to create the django-admin symlink in maintainer
scripts, with the target depending on which of python*-django packages
are installer. This is how src:sphinx manages its /usr/bin/sphinx-*
symlinks.

--
Jakub Wilk

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2014072009...@jwilk.net

Brian May

unread,

Jul 20, 2014, 8:20:01 PM7/20/14

to

On 20 July 2014 19:00, Jakub Wilk <jw...@debian.org> wrote:

One possibility is to write a shell script that is also valid Python code. PoC:

Not sure I understand it (that space in ' ''' seems to be important?), but it seems to work. Thanks.

Another possibility is to create the django-admin symlink in maintainer scripts, with the target depending on which of python*-django packages are installer. This is how src:sphinx manages its /usr/bin/sphinx-* symlinks.

Here we need to be able to specify an exact python version in most cases, as the Python version used depends on the Django app installed. As well as maintain compatibility with existing packages.

So the first approach seems to appropriate one here.

--

Brian May <br...@microcomaustralia.com.au>

Karsten Hilbert

unread,

Jul 21, 2014, 5:10:03 AM7/21/14

to

On Mon, Jul 21, 2014 at 10:17:20AM +1000, Brian May wrote:

> Not sure I understand it (that space in ' ''' seems to be important?),

I would guess it creates a 3-quotes Python string embedded into a single-quote one:

test = ' single-quotes string with: '''3-quotes-string''' embedded into it'

Writing '''' would make the first quote escape the second.

Or some such :-)

Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/2014072109...@hermes.hilbert.loc

Matthias Urlichs

unread,

Jul 21, 2014, 6:20:02 AM7/21/14

to

Hi,

Karsten Hilbert:

> Writing '''' would make the first quote escape the second.
>

Not escape, but …

> Or some such :-)
>
To make this more explicit:

foo=''' '
echo This is Shell code
exec python $0
' '''
print("This is Python")

So to Python, you have a (multiline, hence the triple-quote) string which
contains of a space and a single quote, a linefeed, random text, and the
reverse linefeed-singlequote-space combo.

To the shell, $foo is a single space.

In fact, I would do this slightly differently:

#!/bin/sh
# -*- coding: utf-8 -*-

shell_code=''' '
echo This is Shell
exec python $0

python_code='''
## ONLY use DOUBLE quotes ‹"› after this line
print("This is Python")

# End of Python code. Do not modify this line. #'

This way, "dash -n $SCRIPT" will ignore the Python code
(since it's a string) and not report a syntax error.

--
-- Matthias Urlichs

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/20140721095...@smurf.noris.de