I picked up Ticket #18296 a few months ago, as it relates to some friction I regularly encounter myself. When working in a project where the apps aren’t in the root directory, I need to pass the directory to the startapp command:
python startapp myapp apps/myapp
Which return an error because the directory doesn’t exists:
CommandError: Destination directory '/Users/bruno/.../apps/myapp' does not exist, please create it first.
The fix is quite simple, I can do mkdir apps/myapp and then run the command again, but it always struck me as uncesseray friction. If the directory doesn’t exists, why not go ahead and create it?
I’ve opened Refs #18296 -- Create custom target directory if missing in startproject and startapp by browniebroke · Pull Request #18387 · django/django · GitHub to change the behaviour to fix that specific problem, and was directed to the forum to gather more feedback. so here we are.
Is this change of behaviour desirable?
4 Likes
Did you manage to find any discussion of the existing behaviour? Chesterton’s Gate: was it just an accident it’s how it is, or what breaks if we do change it? If the answer there is nothing then likely it’s an edge we can smooth?
Great question. I didn’t look before but just did a bit of acheology 
As far as I can tell, it’s been like this for ~13 years, since this change (released in Django 1.4) which references ticket #17920.
Reading the ticket, I think the original problem was that the directory wasn’t the full path, but as far as I can tell the logic is now resolving it to be absolute with os.path.abspath(os.path.expanduser(target)), which works correctly even if the director does not exist.
There was actually a comment suggesting to create the missing path:
I’m not sure though whether the target shouldn’t just be created if it doesn’t exist?
I don’t see anything addressing it, so I assume it was overlooked.
2 Likes
@browniebroke Good hustle! That seems kind of convincing to me.
I’m struggling to see any great concern with creating the intermediate directories.
Like, I’m sure it’d upset some purist somewhere, but I struggle to imagine such folks not having the target directory ready in place before invoking the command.
In general it’s got to be the desired behaviour for the vast majority no?
4 Likes
I agree that it makes sense to create the intermediate directories. We should properly handle any error arising from lacking of perms or similar OS errors, but in general I’m in favor!
1 Like
Have we given this topic enough time to gather feedback? If no, how much time is enough time? If yes, I think the current status is that there is no blocker for that change and that people seem fairly in favour of it.
What are the next step to progress the ticket/PR forward? Do I need to update a flag on the ticket to appear in the review queue again or should I leave this to the fellows? There was a comment in the PR regarding documentation, which I happily address if needed.
Thanks everyone for your feedback.
Hello everyone. It seems like the PR has stalled a bit. I think I’ve addressed the suggestions from the fellow but I haven’t heard back in 3 weeks. I appreciate that 5.2 is just around the corner and they might be focused on potential release blockers at the moment, but I’m also worried that I haven’t set the flags of the ticket correctly and it’s not showing up in the review queue. Just want to make sure that it doesn’t fall off the radar!
I also raised some concerned about updating the tutorial straight away:
I’ve updated the tutorial, but now that I think about it, I’m wondering whether now is the right time to do so… If/when this is merged, the tutorial will be published at the dev version (e.g. Writing your first Django app, part 1 | Django documentation | Django) and I assume that some folks might land on this page before v6.0 is released, and would miss the “create directory” step.
Leaving this step in the tutorial still works in v6.0, but removing it would potentially add friction for beginners having an earlier version installed…
I wonder if other folks in here have an opinion on that concern?
You’ve correctly cleared the “patch needs improvement” flag, so the ticket is back in the review pool. (Tip: the “Patches needing review” header on dashboard.djangoproject.com links to that search.) There are currently 45 patches waiting for review. I think your intuition is probably right about other demands on the Fellows’ time lately.
I think that’s OK. The development version documentation is not shown by default, and there’s a yellow banner at the top of every page warning things might work differently in other versions.
(Also, thanks for digging out this old ticket and cleaning up behavior that’s been a stumbling point since Django 1.4.)
1 Like