manage.py should have +x permissions

[pb@…]

manage.py should lead off with #!/usr/bin/env python like django-admin.py does. It should also have execute permissions.

[Adrian Holovaty]

(In [1671]) Fixed #1040 -- Gave manage.py executable permission and added shebang line. Thanks, pb

[anonymous]

Regression: Django v1.3 release doesn't chmod +x the manage.py script.

Environment: Ubuntu 10.x

[Luke Plant]

The script is correct in the 1.3 tarball, and when you run django-admin.py startproject - I presume this must be a Ubuntu packaging bug. Please file a report with them. Thanks.

[anonymous]

Replying to lukeplant:

The script is correct in the 1.3 tarball, and when you run django-admin.py startproject - I presume this must be a Ubuntu packaging bug. Please file a report with them. Thanks.

You presume incorrectly - Ubuntu haven't produced a package yet - I was following the installation instructions as per: ​http://www.djangoproject.com/download/

Searching for the manage.py in the unpacked directory shows...

-rw-r--r-- 1 root   root   503 2011-02-13 01:56 ./build/lib.linux-x86_64-2.6/django/conf/project_template/manage.py
-rwxr-xr-x 1 adrian adrian 503 2011-02-13 01:56 ./django/conf/project_template/manage.py

...which looks as if the executable bit is being lost somewhere in the distutils script.

[Luke Plant]

Sorry, I can now see what you are talking about. However, I'm not sure this is a regression - having just checked Django 1.2 and 1.0, I don't think the executable bit has ever been set correctly in this case.

[Ramiro Morales]

A couple of data points:

• I can reproduce what the OP reports: django/conf/project_template/manage.py in the tree created by uncompressing an official tarball has excutable bits on.
• .../site-packages/django/conf/project_template/manage.py has no executable bits; be it either by installing with python setup.py install from the uncompressed tarball or by running pip install Django, all this in a virtualenv.

Do note that e.g. part one of the Tutorial uses python manage.py <command> but ther is an inconsistency regarding executable bits of manage.py has this inconsistency between a startproject done with e.g. a VCS checkout and with an official release installation.

​Python docs say nothing about executable permission of files that aren't listed in the scripts setup.py section. Perhaps it isn't possible at all?

[anonymous]

Replying to lukeplant:

Sorry, I can now see what you are talking about.

My bad. I was in a bit of a rush when I wrote that report, so it probably wasn't very clear.

However, I'm not sure this is a regression - having just checked Django 1.2 and 1.0, I don't think the executable bit has ever been set correctly in this case.

Okay. Seemed similar, but wasn't sure if it was best to open a new ticket, or just reuse this one. They're kinda the same use-case, i.e. being able to type ./manage.py <args> rather than python manage.py <args>.

Replying to ramiro:

Do note that e.g. part one of the Tutorial uses python manage.py <command>...

Presumably just for Windows-compatibility.

​Python docs say nothing about executable permission of files that aren't listed in the scripts setup.py section. Perhaps it isn't possible at all?

Just found ​an issue report for distutils about this. Adding it into scripts isn't gonna help, e.g. with django-admin.py...

-rwxr-xr-x 1 root root  124 2011-03-23 11:10 /usr/local/bin/django-admin.py
-rw-r--r-- 1 root root  128 2006-12-30 06:25 /usr/local/lib/python2.6/dist-packages/django/bin/django-admin.py

...it only affects the copy which ends up in the bin directory - the copy in lib still gets execute permissions stripped.

There's also another feature of files mentioned in scripts, which is that the shebang line is modified to point to the path returned by which python, which won't be applied to manage.py, although, TBH, I'd prefer they just left as /usr/bin/env python which I generally find more portable, but that's a whole different issue.

Choices would seem to be...

1. Ignore until distutils provides the necessary flexibility
2. Implement custom post-processing in setup.py

...although I can imagine option 2 being a bit of a pain from a cross-platform POV.

IMO option 1 is completely acceptable, since this is all kinda trivial really - it's just a nicety so that Unix-like OS users can save a few keystrokes, and it's not as if it's that difficult for the user to just type chmod +x manage.py. :-)

If you do decide to go with option 1, it might be worth making a note in the docs to that effect.

[Luke Plant]

There is a 3rd option for this - alter the 'startapp' command to fix the permissions for the 'manage.py' after it is copied. This seems nicer than messing around in setup.py. A patch to django/core/management/base.py that special-cased any file named 'manage.py', adding a '_make_executable' function in the style of the existing '_make_writable', would be accepted. No tests necessary, because setup is a pain in this case.

[Flavio Curella]

We could simply set svn propset svn:executable ON django/conf/project_template/manage.py and django.core.management.copy_util function should set the right permission (it already calls shutil.copymode)

I can't 'submit a patch' with that change, someone with commit bit will have to do it and commit.

My only doubt about this solution is about how portable is, VCS-wise. In case this is a no-no, I'll write a patch that just manully assign +x to manage.py.

[Flavio Curella]

changed the ticket summary, since manage.py DOES have the shebang

[Flavio Curella]

After double checking, I was wrong.

manage.py's permissions are already set correctly in SVN.

The problem appears when installing from PyPi (eg: via pip install django).

[Flavio Curella]

I've added a line to the startproject command that set the permission to manage.py

[Flavio Curella]

This is actually a pip and not a PyPi issue, as documented in ​https://github.com/pypa/pip/issues/317

Setting this as wontfix as fixing pip's behavior is out of the scope for the Django project.