StuartMacKay/django-project-template

Remove views, tests, etc.

Opened this issue · 0 comments

A more minimalist app might be easier to get started since there is less to remove. Since adding django-watchman there is an easy way of verifying everything as working. Consequently there is less need for a basic set of reviews and tests that will likely be removed:

  • Prune the existing views?
  • Prune the existing tests?
  • Remove the test mixins?

Alternatively replace these with something more useful.

Pending - leave them in for now to see if there is real value after creating a couple of projects with the template.

UPDATE: 15th Jan 2024

Based on experience of starting a new project with the template (the previous work was upgrading existing projects to standardise the layout) the following "things" came up:

apps should be moved out to the backend directory.

Repeatedly typing project.apps while apparently innocuous, soon became tedious. Within a project the to elements to the module path, project and apps are unique so there's no real point in using both. So apps wins.

The original motivation for make apps a sub-directory of project was to create a single point for project-wide searches, since the virtualenv also exists in the backend directory. However, this one can be attributed to author incompetence as PyCharm provides scoped searches where only project files are included. That means that if the virtualenv is marked as excluded you can perform a scoped search on the backend directory and only results for the project will be displayed. Case closed.

tests should be moved out to the backend directory.

This was somewhat unexpected. The original idea that having everything in the same place is always good. However, for more complex apps there might be several levels for modules, for example, myapp.models.helpers.loaders. Now if the tests are organised in the same way as the app then the tests for the loaders live in myapp.tests.models.helpers.loaders. The problem comes with importing the code to test. Either you do:

from ....models.helpers.loaders import mycode

or

from project.apps.myapp.models.helpers.loaders import mycode

Neither are particularly pretty or desirable. However relative imports four levels up look a bit weird so the absolute path wins out.

Now, with apps moved to the project root the absolute import looks more appealing:

from apps.myapp.models.helpers.loadersgg

clean out project.tests

project.tests was originally intended to store reusable stuff like the factory objects for generating test data. Now with tests moved out to the root directory, project.test needs to be cleaned out and it looks like the existing example classes can be deleted.