Code

Opened 7 years ago

Closed 7 years ago

#3475 closed (wontfix)

Creating apps with certain names causes manage.py to stop working

Reported by: svant Owned by: nobody
Component: Core (Management commands) Version: master
Severity: Keywords: manage.py, startapp
Cc: frankie@…, jdunck@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

manage.py should not allow creating an app with a certain name when that could break manage.py itself.

after doing manage.py startapp site I got the following error when trying to do something with manage.py

Traceback (most recent call last):
  File "path\manage.py", line 2, in ?
    from django.core.management import execute_manager
ImportError: No module named django.core.management

Attachments (3)

invalid_app_names.patch (1014 bytes) - added by frankie@… 7 years ago.
Against [4485]
invalid_app_names.2.patch (1018 bytes) - added by frankie@… 7 years ago.
Oopsie, typo
invalid_app_and_project_names.patch (2.4 KB) - added by frankie@… 7 years ago.
This patch check for invalid project and app names in the way previously mentioned.

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by frankie@…

Against [4485]

Changed 7 years ago by frankie@…

Oopsie, typo

comment:1 Changed 7 years ago by frankie@…

  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Ready for checkin

comment:2 Changed 7 years ago by mtredinnick

  • Triage Stage changed from Ready for checkin to Design decision needed

(Only triagers and committers should move tickets between stages, please.)

I think we need to think about how far we want to go here. Do we put every standard Python module in the list? If not, why do we only put some in?

I'm probably -1 on this idea at the moment, because it's so hard to draw the line and not naming your modeuls after standard Python modules is not a Django-specific requirement.

comment:3 Changed 7 years ago by frankie@…

Oops, is triage limited to an exclusive bunch or am I just excluded from triage because of doing the patch?

Anyway, yeah. I agree. As far as I can see there are too solutions:

  1. Don't do any checking. This is fair enough, but in this case project names should not be checked either.
  1. Make checking more dynamic. As in eval() it and if it comes out as anything but NameError say it's invalid.

Changed 7 years ago by frankie@…

This patch check for invalid project and app names in the way previously mentioned.

comment:4 Changed 7 years ago by anonymous

  • Cc frankie@… added

comment:5 Changed 7 years ago by anonymous

  • Cc jdunck@… added

comment:6 Changed 7 years ago by Simon G. <dev@…>

#4850 is a related issue.

comment:7 Changed 7 years ago by mtredinnick

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

The problem with this is it's a false sense of security. It doesn't prevent you creating a problem later without knowing what went wrong. You always need to be aware of name collisions and we can't really protect people from that.

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.