AppConfig.name should be a full python path when using the optional directory.

[JungChaeMoon]

Currently, If someone calls the startapp command with a target directory argument, the generated AppConfig.name is wrong.
It has to be a python path of app not just name of app.
So, users have to reset the attribute oneself.

In the document, 'AppConfig.name' is defined as follows.

AppConfig.name

Full Python path to the application, e.g. 'django.contrib.admin'.

This attribute defines which application the configuration applies to. It must be set in all AppConfig subclasses.

It must be unique across a Django project.

​https://docs.djangoproject.com/en/2.2/ref/applications/#django.apps.AppConfig.name

So, I belive that It has to be a path of app.

[Mariusz Felisiak]

​PR

[Mariusz Felisiak]

I'm sorry, but I realized that we will not be able to handle all cases properly and that this patch can cause regressions for people that call manage.py for other directories, e.g.

python myproject/manage.py startapp test_app myproject/test_other_name

It is ​documented that startapp uses app_name as passed to the command and I believe that we should keep this behavior. Thanks for your efforts!

[David Sanders]

Felix, Sarah, Nessita, is this approach worth considering:

Someone requested this in the Django new-features repo (see point 2 on: ​https://github.com/django/new-features/issues/62), so I reported it at #36536 but Sarah pointed out this ticket.

I believe we can address this but using this approach:

• Use settings.BASE_DIR and os.path.relpath() to compare with the supplied target directory (instead of using cwd)
• If settings.BASE_DIR was never specified (or removed as startproject sets it) then simply use app_name
• If the relative path is outside settings.BASE_DIR then ignore it and also revert to using app_name
• If within the project then convert to python path and use that instead.

[Sarah Boyce]

I think one thing we would struggle with is custom templates for the startapp command, as documented:

The template context used for all matching files is:

• Any option passed to the startapp command (among the command’s supported options)
• app_name – the app name as passed to the command

So you will either update app_name in the context to not be what it is defined here, or you will add something new to the template context (and existing templates may want to update their template).
Also in Mariusz's example, python myproject/manage.py startapp test_app myproject/test_other_name I am not sure what the expected result would be? To ignore the passed in app_name completely?

[David Sanders]

Ah yeah if you want to continue supporting supplied templates then I suppose a new context variable app_path might be the go to avoid breaking things.

I'm not sure whether Mariusz' example was demonstrating calling manage.py from a different dir or having a different directory name test_other_name (or both) but I think we could come up with a reasonable result for both cases? 🤔

[Sarah Boyce]

So I guess each case just needs discussion and agreement. We have identified things that would be potentially "breaking changes", so we need an agreement of a path forward
The new features discussion (​​https://github.com/django/new-features/issues/62) might be the best place to build that proposal