Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typical place to create app in cookiecutter-django #1876

Closed
playma opened this issue Nov 23, 2018 · 20 comments · May be fixed by #3358
Closed

Typical place to create app in cookiecutter-django #1876

playma opened this issue Nov 23, 2018 · 20 comments · May be fixed by #3358

Comments

@playma
Copy link

playma commented Nov 23, 2018

I have a question.
Startapp creates the app in the first level, the same directory where manage.py is.
Why not create the app in the <project_name>/ level, where also the users app is?

@ahhda
Copy link
Contributor

ahhda commented Dec 18, 2018

I think this has been tried before (See #1725 ). The django startapp, apparently, was not projected to be extended.

@playma
Copy link
Author

playma commented Dec 19, 2018

@ahhda Thank you for your reply, but I just want to check where should I create the app (in the first level or second level). #1725 only discussed how to move the app from the first level to the second level.

@ahhda
Copy link
Contributor

ahhda commented Dec 19, 2018

@playma cookiecutter-django defines apps inside project folder.
Therefore the canonical place is inside the the project folder (second level), otherwise the root folder gets littered with too much stuff.

@webyneter
Copy link
Collaborator

Yes, the second level is the right place for your Django apps.
FWIW, I personally do not use the srartapp command, and just create a Django package with apps.py myself, as well as reference it in settings. This is what a typical apps.py looks like for me (and I don't even have to write the most part of it since I have it generated from a PyCharm Live Template of mine):

# apps.py in your new shiny Django app under the project's root `<project_slug>/` dir

from django.apps import AppConfig
from django.utils.translation import ugettext_lazy as _


class <YourCamelCaseAppName>AppConfig(AppConfig):
    name = "<project_slug>.<your_snake_case_app_name>"
    verbose_name = _("<Your app brand name>")

    def ready(self):
        try:
            # noinspection PyUnresolvedReferences
            from . import signals  # noqa F401
        except ImportError:
            pass

And this where you should install your new app:

# `base.py`

# ...
LOCAL_APPS = [
    # ...
    "<project_slug>.<your_snake_case_app_name>.apps.<YourCamelCaseAppName>AppConfig",
    # ...
]
# ...

Should you need that specific app installed in some specific environment only, provided that environment has an associated settings file like local.py or production.py:

# anywhere else but in `base.py`

# ...
INSTALLED_APPS += ["<project_slug>.<your_snake_case_app_name>.apps.<YourCamelCaseAppName>AppConfig"]
# ...

@reyesvicente
Copy link
Contributor

Hi, does this mean we don't need to include the new app on the urls.py?

@webyneter
Copy link
Collaborator

It depends: if your app contains urls you'd like to expose to the outer world then you gotta include those urls from the root urls.py via include.

@reyesvicente
Copy link
Contributor

Thats weird. I tried to include it but it doesn't recognize my app and returns ModuleNotFoundError: No module named '<project_slug>.<app_name>.urls'

@webyneter
Copy link
Collaborator

If your app contains models did you install it into INSTALLED_APPS?

@reyesvicente
Copy link
Contributor

Yes, I followed the instructions here. 😄

@reyesvicente
Copy link
Contributor

Screen Shot 2019-10-19 at 3 11 00 PM

@webyneter
Copy link
Collaborator

Try including the app under a different root, like "pages/" rather than ""`

@webyneter
Copy link
Collaborator

Also, did you specify app_name="pages" in icvn/pages/urls.py?

@reyesvicente
Copy link
Contributor

Also, did you specify app_name="pages" in icvn/pages/urls.py?

Yes I did. I followed what was here on this comment on this thread.

I tried also including pages/ on the urls.py but it didn't work

@reyesvicente
Copy link
Contributor

This is my apps.py

from django.apps import AppConfig
from django.utils.translation import ugettext_lazy as _


class PagesConfig(AppConfig):
    name = "icvn.pages"
    verbose_name = _("Pages")

    def ready(self):
        try:
            from . import signals
        except ImportError:
            pass

@webyneter
Copy link
Collaborator

Hm, then, I can't say for sure what's wrong without inspecting the code base first. My email is posted on my github profile, feel free to reach out.

@reyesvicente
Copy link
Contributor

Hm, then, I can't say for sure what's wrong without inspecting the code base first. My email is posted on my github profile, feel free to reach out.

Cool. I just sent an email.

@webyneter
Copy link
Collaborator

@reyesvicente I'll get back to you by the end of the weekend.

@reyesvicente
Copy link
Contributor

@reyesvicente I'll get back to you by the end of the weekend.

Thanks!

@webyneter
Copy link
Collaborator

@reyesvicente you don't actually have icvn,pages.urls module, hence the error. An empty one would suffice, for instance:

# icvn/pages/urls.py

app_name = "pages"
urlpatterns = [
]

You may also replace the config/urls.py path("pages/", include('icvn.pages.urls', namespace='pages')), line with just path("pages/", include('icvn.pages.urls')),, just make sure to specify app_name in the referenced routes file.

@reyesvicente
Copy link
Contributor

@reyesvicente you don't actually have icvn,pages.urls module, hence the error. An empty one would suffice, for instance:

# icvn/pages/urls.py

app_name = "pages"
urlpatterns = [
]

You may also replace the config/urls.py path("pages/", include('icvn.pages.urls', namespace='pages')), line with just path("pages/", include('icvn.pages.urls')),, just make sure to specify app_name in the referenced routes file.

It worked! Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants