django-admin.py shebang

[Stan]

Hi devs,

Is there a good reason for having the shebang line in django-admin.py at #!/usr/bin/python
"instead" of #!/usr/bin/env python ?

My problem is I have a newer version of Python installed in /usr/local/opt/ declared in my PATH
that I want to test but the hardcoded path to /usr/bin/python ignore the PATH value.

I know that virtualenv is the way to go...

Thanks !

--
Stan

[Collin Anderson]

Hi Stan,

In the source, it's looks like it's been using #!/usr/bin/env python for almost 10 years:

https://github.com/django/django/blame/master/django/bin/django-admin.py

My quick guess is that gets modified when installing. Did you use the newer version of python to install django?

Collin

[Markus Holtermann]

Hi Stan,

how did you install Django? As a system package via the system's package manager or via pip. If its the system package manager, please raise that bug in the bug tracker of your Linux distribution. If the answer is "via pip", from where? PyPI or something obscure?

As Collin already wrote, Django uses "/usr/bin/env python" for years.

/Markus

On April 1, 2015 3:58:13 PM GMT+02:00, Collin Anderson <cmawe...@gmail.com> wrote:
>Hi Stan,
>
>In the source, it's looks like it's been using #!/usr/bin/env python
>for
>almost 10 years:
>https://github.com/django/django/blame/master/django/bin/django-admin.py
>
>My quick guess is that gets modified when installing. Did you use the
>newer
>version of python to install django?
>
>Collin
>
>On Wednesday, April 1, 2015 at 7:46:34 AM UTC-4, Stan wrote:
>>
>> Hi devs,
>>
>> Is there a good reason for having the shebang line in django-admin.py
>at
>> #!/usr/bin/python
>> "instead" of #!/usr/bin/env python ?
>>
>> My problem is I have a newer version of Python installed in

>> */usr/local/opt/* declared in my PATH

[Stan]

On Wednesday, April 1, 2015 at 3:58:13 PM UTC+2, Collin Anderson wrote:

Hi Stan,

In the source, it's looks like it's been using #!/usr/bin/env python for almost 10 years:

https://github.com/django/django/blame/master/django/bin/django-admin.py

I didn't check that...
 

My quick guess is that gets modified when installing. Did you use the newer version of python to install django?

No, it was installed with the Debian Wheezy package version (2.7.3). Thanks for the tips.

--
Stan

[Stan]

On Wednesday, April 1, 2015 at 4:15:25 PM UTC+2, Markus Holtermann wrote:

Hi Stan,

how did you install Django? As a system package via the system's package manager or via pip. If its the system package manager, please raise that bug in the bug tracker of your Linux distribution. If the answer is "via pip", from where? PyPI or something obscure?

A classical pip install Django command without --mirrors or --use-mirrors modifier.

I did some --upgrade, but the first installation is not 10 years old (2 maybe).

 
Pip is a Debian package (1.1.3)

[$ whereis django-admin
django-admin: /usr/local/bin/django-admin.py /usr/local/bin/django-admin
$ cat /usr/local/bin/django-admin
#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'Django==1.7.4','console_scripts','django-admin'
__requires__ = 'Django==1.7.4'
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
    sys.exit(
        load_entry_point('Django==1.7.4', 'console_scripts', 'django-admin')()
    )
$ cat /usr/local/bin/django-admin.py
#!/usr/bin/python
from django.core import management

if __name__ == "__main__":
    management.execute_from_command_line()

[James Bennett]

On Wed, Apr 1, 2015 at 10:28 AM, Stan <stanisla...@gmail.com> wrote:

A classical pip install Django command without --mirrors or --use-mirrors modifier.

I did some --upgrade, but the first installation is not 10 years old (2 maybe).

 
Pip is a Debian package (1.1.3)

[$ whereis django-admin
django-admin: /usr/local/bin/django-admin.py /usr/local/bin/django-admin

This right here is the giveaway that what you're looking at is Debian's version of Django (they modify the name from 'django-admin.py' to 'django-admin' to suit their policies for file naming).

[Collin Anderson]

Hi Stan,

If possible, I'd recommend (somehow) getting a pip built against your /usr/local/bin/python, then "/usr/local/bin/pip install django" should do what you want.

Collin

[Florian Apolloner]

On Wednesday, April 1, 2015 at 5:34:55 PM UTC+2, James Bennett wrote:

This right here is the giveaway that what you're looking at is Debian's version of Django (they modify the name from 'django-admin.py' to 'django-admin' to suit their policies for file naming).

Newer Django versions have it as django-admin too! https://github.com/django/django/blob/master/setup.py#L47-L49

[Shai Berger]

On Wednesday 01 April 2015 18:34:35 James Bennett wrote:
> On Wed, Apr 1, 2015 at 10:28 AM, Stan <stanisla...@gmail.com> wrote:
> > A classical pip install Django command without --mirrors or --use-mirrors
> > modifier.
> >
> > I did some --upgrade, but the first installation is not 10 years old (2
> > maybe).
> >
> >
> > Pip is a Debian package (1.1.3)
> >
> > [$ whereis django-admin
> > django-admin: /usr/local/bin/django-admin.py /usr/local/bin/django-admin
>
> This right here is the giveaway that what you're looking at is Debian's
> version of Django

Actually, it proves the opposie. Debian's packages don't install into
/usr/local/bin, but into /usr/bin.

Also, I've just checked -- Debian's django-admin is a bash script, with
#!/bin/sh.

Shai.

[frantisek holop]

Stan, 01 Apr 2015 04:46:

> Hi devs,
>
> Is there a good reason for having the shebang line in django-admin.py at
> #!/usr/bin/python
> "instead" of #!/usr/bin/env python ?

is there a good reason to use the latter?

"env python" is a terrible hack for systems that
are way behind with their "official" packages.
it creates a nightmare when multiple python
versions are installed.

when outside virtualenv, i prefer the first
version exactly for the same reason you
prefer the latter: so that the interpreter
used is deterministic -- the system one --
instead of who knows what that could be picked
up from the user's PATH...

it is the same reason why the current path ('.')
should be the last element of PATH: so that
a local executable named after an existing
system-wide program is not shadowing it, creating
potentially difficult to track down problems.
"explicit is better than implicit", right?

if you want to override the path to the interpreter,
put it on the command line. otherwise a simple
change in PATH could break the whole application.

-f
--
xerox never comes up with something original.