Code

Opened 2 years ago

Last modified 11 months ago

#18296 new Cleanup/optimization

Make creating apps inside project folder more intuitive with manage.py startapp command

Reported by: lgp171188@… Owned by: vanessagomes
Component: Core (Management commands) Version: 1.5
Severity: Normal Keywords: manage.py, startapp
Cc: vanessagomes Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The structure of the project created by 'django-admin.py startproject' has changed from Django 1.4. The 'manage.py' file is at the same level where the project folder containing settings.py, urls.py is present. In order to create an app within the project as was possible with Django < 1.4, the command to be used is 'python manage.py startapp <app name> <destination folder which is optional>. So if I execute the command "python manage.py startapp myapp myproject", there is an error that says "Error: <full path>/<project name>/<project name>/init.py already exists, overlaying a project or app into an existing directory won't replace conflicting files". The command actually expects an empty directory having the name of the app inside the project directory to work correctly. So the user has to create that directory and then create the app. This isn't very intuitive and django should create the app directory if it doesn't exist and then create the app to show the same behaviour as the previous versions.

One other way to work around this behaviour is to change to the project directory and then execute python ../manage.py startapp appname.

Attachments (1)

ticket18296.diff (3.1 KB) - added by vanessagomes 2 years ago.
I'm sorry guys, it was another ticket that I was soluting, and it came together. Now is the right patch.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 2 years ago by jezdez

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 2 years ago by vanessagomes

  • Owner changed from nobody to vanessagomes

comment:3 Changed 2 years ago by vanessagomes

  • Owner vanessagomes deleted

comment:4 Changed 2 years ago by vanessagomes

  • Owner set to vanessagomes

comment:5 Changed 2 years ago by SmileyChris

I agree that it's pretty unintuitive.

Both commands use the same base class, but it doesn't take into acount that creating a project involves creating a workspace containing the project module, whereas an app is nothing *but* the module -- you can't put an app named 'app1' in anything but an app1 directory.

comment:6 Changed 2 years ago by SmileyChris

Talking with Vanessa, we teased out the backwards incompatibilities of always creating the app folder.

One may assume the command should always create the app folder (i.e. move the contents of django/conf/template to django/conf/template/app_name). Unfortunately, it's not that easy - because then without a target, you'd end up with app_name/app_name

One solution is to only create the app folder if the target folder's basename differs from the app name. This means that we keep backwards compatibility, but at the cost of less consistent behaviour.

The more consistent way would be to always create the app_name subdirectory when dealing with an explicit target. Again though, this changes the contract from the current behaviour.

Last edited 2 years ago by SmileyChris (previous) (diff)

comment:7 Changed 2 years ago by vanessagomes

  • Cc vanessagomes added
  • Easy pickings unset
  • Has patch set

It was created a method who get the target's directory. And in startapp.py, the get_target_dir() was overrided to deal with this special issue.

So, when you use

python manage.py startapp myapp1

or

python manage.py startapp myapp2 myproject

It's working well.

comment:8 Changed 2 years ago by hvdklauw

  • Patch needs improvement set

Why is the get_backend_info stuff in the diff? It's totally unrelated. You might have accidentally left another patch in there.

Changed 2 years ago by vanessagomes

I'm sorry guys, it was another ticket that I was soluting, and it came together. Now is the right patch.

comment:9 Changed 2 years ago by vanessagomes

  • Cc vanessagomes removed
  • Patch needs improvement unset

I replaced the old patch, and Now we have the right patch.

comment:10 Changed 2 years ago by ptone

  • Needs tests set

Thanks for the work on this.

To be clear, this is not a bug. For the currently documented behavior, this should never work:

(django-dev)element:tmp$ django-admin.py startproject myproject
(django-dev)element:tmp$ cd myproject
(django-dev)element:myproject$ ./manage.py startapp myapp myproject

Because the destination argument to startapp should be a folder *into which* the app package contents are injected, not a containing folder, if that sequence ran without error, it would result in an app and a project inside the same python package (sharing a single init, having a models.py next to a settings.py etc).

The docs are: "If the optional destination is provided, Django will use that existing directory rather than creating a new one. You can use '.' to denote the current working directory."

If you instead meant:

./manage.py startapp myapp myproject/somedir

you instead get an error about the directory not existing and to create it first - I'm not sure that Django shouldn't just create it if it doesn't exist - that would be a different ticket.

If you see a way to clarify the docs on this, perhaps a documentation ticket could be opened as well?

I see doing:

cd myproject
../manage.py startapp myapp
or 
django-admin.py startapp myapp

as preferable to a backwards incompatible design change as proposed by the patch - but that is getting into DDN territory...

comment:11 Changed 2 years ago by vanessagomes

  • Cc vanessagomes added

I think we should open a new ticket about the docs, so we can discuss if we should change a little bit of...

comment:12 Changed 11 months ago by anonymous

this link might be useful to Create an app in a sub-directory : http://stackoverflow.com/questions/12841565/django-cant-create-app-in-subfolder

comment:13 Changed 11 months ago by anonymous

  • Resolution set to fixed
  • Status changed from new to closed
  • Version changed from 1.4 to 1.5
mkdir Apps\newapp
python manage.py startapp NewApp Apps/newapp
python manage.py startapp myApp ./Apps/myApp

src:
http://stackoverflow.com/questions/12841565/django-cant-create-app-in-subfolder
https://docs.djangoproject.com/en/1.4/ref/django-admin/#startapp-appname-destination

comment:14 Changed 11 months ago by aaugustin

  • Resolution fixed deleted
  • Status changed from closed to new

The discussion above contains several ideas that weren't taken into account or rejected; the ticket isn't fixed until we make a decision.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from vanessagomes to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


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

 
Note: See TracTickets for help on using tickets.