Opened 18 years ago

Closed 13 years ago

#1040 closed New feature (wontfix)

manage.py should have +x permissions

Reported by: pb@… Owned by: Flavio Curella
Component: Core (Management commands) Version: dev
Severity: Normal Keywords:
Cc: Flavio Curella Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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

Attachments (1)

1040.diff (606 bytes ) - added by Flavio Curella 13 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 by Adrian Holovaty, 18 years ago

Resolution: fixed
Status: newclosed

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

comment:2 by anonymous, 13 years ago

Resolution: fixed
Status: closedreopened

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

Environment: Ubuntu 10.x

comment:3 by Luke Plant, 13 years ago

Resolution: fixed
Status: reopenedclosed

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.

in reply to:  3 comment:4 by anonymous, 13 years ago

Resolution: fixed
Status: closedreopened

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.

comment:5 by Luke Plant, 13 years ago

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.

comment:6 by Ramiro Morales, 13 years ago

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 there is an inconsistency regarding executable bits of manage.py 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?

Last edited 13 years ago by Ramiro Morales (previous) (diff)

in reply to:  6 comment:7 by anonymous, 13 years ago

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.

comment:8 by Łukasz Rekucki, 13 years ago

Severity: normalNormal
Type: defectNew feature

comment:9 by Luke Plant, 13 years ago

Triage Stage: UnreviewedAccepted

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.

comment:10 by Flavio Curella, 13 years ago

Easy pickings: unset
UI/UX: unset

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.

Last edited 13 years ago by Flavio Curella (previous) (diff)

comment:11 by Flavio Curella, 13 years ago

Cc: Flavio Curella added

comment:12 by Flavio Curella, 13 years ago

Summary: manage.py should have shebang and +x permissionsmanage.py should have +x permissions

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

comment:13 by Flavio Curella, 13 years ago

Owner: changed from Adrian Holovaty to Flavio Curella
Status: reopenednew

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).

by Flavio Curella, 13 years ago

Attachment: 1040.diff added

comment:14 by Flavio Curella, 13 years ago

Has patch: set
Needs tests: set

comment:15 by Flavio Curella, 13 years ago

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

comment:16 by Flavio Curella, 13 years ago

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top