Hi John! Thanks for taking the time to compile a detailed bug report. Unfortunately, emailing django-developers isn't the right approach here - the mailing list is normally for higher level discussion. The normal process is to write a ticket on Trac, our ticket tracker: https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/
I'd do it for you right now, but then you won't be subscribed to the ticket and able to answer replies. If you could take the time to submit it as per the guide, then we can have a proper conversation on Trac. For what it's worth, at first glance I think you may have a bug here, and it might be worth adding some more logic for where new apps can be placed by startapp. Thanks, Adam On Fri, 5 Jul 2019 at 20:51, John Gooding <[email protected]> wrote: > To be clear, I am not saying there is a bug. It does what it is programmed > to do. I am saying the expected behavior of the API / CLI / whatever you > want to call it is inconsistent. > > I am not going to get into an argument of what a "proper" django structure > is, etc. I want to focus purely on the behavior of the command. > > A more "normal" setup might look like this: > > /repository > manage.py > /project > settings.py > urls.py > etc.. > /polls > models.py > etc... > > When you run `python manage.py startapp polls` from the same directory as > manage.py, it will create the polls directory for you, normal expected > behavior. > > Another, equally as valid setup looks like this: > > repository/ > manage.py > /project > settings.py > urls.py > etc... > /polls > models.py > etc... > /my_app_2 > models.py > etc... > > Where all of the apps live in the project directory, or perhaps some other > directory. Now if you try to execute `python manage.py startapp polls > project`, it will complain that the directory doesn't exist and that you > need to create it first. However if you `cd` into /project, and run `python > ../manage.py startapp polls`, it will create the directory for you, even > though it doesn't exist. > > My ultimate point is this, the behavior of the command should not depend > on where it is ran. It should only care if the directory already exists or > not, which it does check, but the applied behavior of that check is > different depending on if you're in the line 68 if block > <https://github.com/django/django/blob/53209f78302a639032afabf5326d28d4ddd9d03c/django/core/management/templates.py#L68> > or > the line 76 else block > <https://github.com/django/django/blob/53209f78302a639032afabf5326d28d4ddd9d03c/django/core/management/templates.py#L76>. > The applied behavior ought to be the same, regardless of where the command > is ran from. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/dfe324ce-3718-4379-b20e-a2703973869c%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/dfe324ce-3718-4379-b20e-a2703973869c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1EKO%2B6ZAYzoduC0tan1iy8Fbug1aKDUHKvzHxG6TsO5w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
