![]() ![]() I prefer Tailwind over Bootstrap, Bulma and other CSS frameworks, at least as a starter default, so I'll probably have a in the top directory as well. These days I tend to start with a more lightweight frontend but if I'm building a full SPA the static files will probably live in their own frontend directory at the top level of the project (or an entirely different repo). The dist directory contains any files generated by whatever frontend build system (django-compress, esbuild, webpack etc) such as minified/processed CSS and Javascript/sourcemap files. Static files also live under the top directory: myproject Rule of thumb: if I have to a template (or access it using an inclusion template tag) it goes in the relevant includes subdirectory, unless the include has a specific function like pagination, forms etc. The top level templates directory will have a "junk drawer" includes directory (in addition to specific includes for things like pagination templates) and individual apps will have their own includes: myproject This is just a personal preference thing, but it avoids a directory becoming too large with similarly named files. Nowadays I prefer to move partials under an includes subdirectory and avoid the underscore naming. For a while I used the underscore convention for example _article.html as opposed to a non-partial article.html. I've gone back-and-forth on naming individual templates and subdirectories, particularly regarding partials. Keeping them in one easily-accessible place is nice and consistent, particularly if non-Django developers (say frontend people) want to work on them and don't particularly want to have to hunt around in different apps trying to find the right file (the same goes, of course, for static files). Generally I avoid per-app templates, but keep the templates all in one place under the top-level directory. INSTALLED_APPS = INSTALLED_APPS + Templates # INSTALLED_APPS = INSTALLED_APPS + įrom split_settings. For example in local.py instead of this: from. To keep settings maintainable I use django-environ to use environment variables as much as possible, and django-split-settings to keep inter-settings imports nice and tidy. Personally I dislike the extra typing that involves. Some people like to have an extra level or use a config package or something like that. My typical settings structure will look something like this: myproject Perhaps not as comprehensive as django-stubs but good enough to provide some benefit to typing. I have tried mypy with django-stubs, but found it a massive pain to work with due to need to run it inside the Docker container (among other problems), so I just use mypy with these settings: My pre-commit file typically includes (in addition to standard whitespace checking etc): flake8 (because Flake doesn't support pyproject.toml) At present though I just start with a plain Django project and make the changes I need manually. I would probably keep a cookiecutter if a) there were other maintainers who could help keep it up to date or b) I was running an agency where I make new projects every other week and a cookiecutter saves perhaps days of work each time, and there is a need to maintain a base level of quality and consistency. Over time the cookiecutter drifts away from your latest projects and thinking. You want to keep adding new things to the cookiecutter to reflect your learning in your Django projects, and you also want to keep up with latest changes in the ecosystem - for example, a best-of-breed library falls out of favour in place of the next hot thing. ![]() I've tried a couple times, but they're a pain to maintain. I also do not maintain my own cookiecutter. Personally I find it a little too large, and it has a lot of artefacts I don't need, but I still use it as a reference for current thinking about best practices in Django. If you have never built a large Django project before you could do far worse than use this. What does a "good" project skeleton look like? Cookiecutters #Īt this point some people will recommend using a cookiecutter, and the best supported and maintained right now is Daniel Roy Greenfeld's Django cookiecutter. Maybe a virtualenv and that's that.īut say it's a serious project that is likely to have legs. I won't need anything more than Sqlite and I definitely won't need Docker. If it's just a quick throwaway, for a tutorial or proof-of-concept, I just type django-admin.py startproject and go with all the defaults. ![]() Usually this is just some side project: very occasionally I get to build a greenfield project for someone else (protip for new developers: 99.99% of your career you'll be inheriting someone else's project, for better or worse). Occasionally I get to start over with a new Django project. Starting a New Django Project django python web development ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |