Code

Opened 9 years ago

Closed 3 years ago

#1040 closed New feature (wontfix)

manage.py should have +x permissions

Reported by: pb@… Owned by: fcurella
Component: Core (Management commands) Version: master
Severity: Normal Keywords:
Cc: fcurella 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 fcurella 3 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 9 years ago by adrian

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:2 Changed 3 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

Environment: Ubuntu 10.x

comment:3 follow-up: Changed 3 years ago by lukeplant

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

comment:4 in reply to: ↑ 3 Changed 3 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

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 Changed 3 years ago by lukeplant

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 follow-up: Changed 3 years ago by ramiro

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 3 years ago by ramiro (previous) (diff)

comment:7 in reply to: ↑ 6 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by lrekucki

  • Severity changed from normal to Normal
  • Type changed from defect to New feature

comment:9 Changed 3 years ago by lukeplant

  • Triage Stage changed from Unreviewed to Accepted

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 Changed 3 years ago by fcurella

  • 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 3 years ago by fcurella (previous) (diff)

comment:11 Changed 3 years ago by fcurella

  • Cc fcurella added

comment:12 Changed 3 years ago by fcurella

  • Summary changed from manage.py should have shebang and +x permissions to manage.py should have +x permissions

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

comment:13 Changed 3 years ago by fcurella

  • Owner changed from adrian to fcurella
  • Status changed from reopened to new

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

Changed 3 years ago by fcurella

comment:14 Changed 3 years ago by fcurella

  • Has patch set
  • Needs tests set

comment:15 Changed 3 years ago by fcurella

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

comment:16 Changed 3 years ago by fcurella

  • Resolution set to wontfix
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.