Earlier quoted context omitted.
oh the automatic migrations scare the bejesus out of me. i really prefer writing out schemas and migrations like in elixir/ecto. plus i like the option of having two different schemas for the same table (even if i never use it)
The nice thing in this case is that Django will meet you where you are with your preferences. Want to go the manual route? Sure. Want it to take a shot at auto-generation and then you customize? Very doable and. Want to let Django take the wheel fully the majority of the time? Sure.
Some notes on starting to use Django
91–100 of 145 posts
Re: Some notes on starting to use Django
#92Re: Some notes on starting to use Django
#93Earlier quoted context omitted.
Build fast and break things works great if you're the consumer, not the dev polishing the dark side of the monolith (helps if you're getting paid well though)
As a consumer, I can not remember any feature that I was so enamored about having a week earlier than I otherwise would have, at the expense of breaking things.
Re: Some notes on starting to use Django
#94Some more Django recommendations from Frank Wiles of Revsys (Django consultancy): https://frankwiles.com/questions/starting-django-projects/ I'll add a few of my own: * Set up the project using uv * I name the django project "project"; so settings are project/settings.py, main urls are project/urls.py, etc * I always define a custom Django user model even if I don't need anything extra yet; easier to expand later * s…
> use python-dotenv to pull settings from environment / .env I disagree strongly with this one. All you are doing is moving those settings to a different file. You might as well use a local settings file that reads the common settings. On production keep things like API keys that need to be kept secret elsewhere - as a minimum outside the project directories and owned by a different user.
Re: Some notes on starting to use Django
#95Earlier quoted context omitted.
Can you give an example how this would happen?
Ok, from memory -- There's a pre, do and post phase for the migrations. When you run a single migration, it's: pre, do, post. When you run 2 migrations, it's: pre [1,2], do: [1,2], post: [1,2]. So, if you have a migration that depends on a previous migration's post phase, then it will fail if it is run in a batch with the previous migration. When I've run into this is with data migrations, or if you're adding/assigin…
Re: Some notes on starting to use Django
#96The author makes a great last point about Settings and it’s something I’ve not considered… ever! I wonder if there’s a feature request for this because having a pre-configured object would be nice for the ability to verify correctness on startup.
In TypeScript, I use the same validation library (Zod) anywhere I need to validate data. So, I validate my config / environment variables on startup using a Zod schema, I validate my RPC endpoint arguments the same way, etc. I presume you could do the same thing with Django— use Django’s validation feature to validate everything including your config. It’s a nice pattern that gives uniformity and predictability to al…
The situation is worse than that because any plugins usually define their own settings which also don’t validate their contents.
I think something centralised that lets you properly scope and validate settings would be nice. If you mistype a key, you’d want an error that it’s just not valid.
Re: Some notes on starting to use Django
#97For anybody starting with Django, I had written a bunch of guidelines some years ago https://spapas.github.io/2022/09/28/django-guidelines/ (after more than 10 years using exclusively Django for my work)
Re: Some notes on starting to use Django
#98Re: Some notes on starting to use Django
#99Earlier quoted context omitted.
I'll add one; Add shell_plus. It makes the django shell so much nicer to use, especially on larger projects (mostly because it auto-imports all your models). IIRC, it involves adding ipython and django_extensions as a dependency, and then adding django-extensions (annoyingly, note that the underscore changes to a dash, this trips me up everytime I add it) to your installed apps. Saying that, I'm sure django-extension…
> mostly because it auto-imports all your models Django does this by default now. Since 5.0 if I'm remembering it correctly.
Edit: Yep, you're right, wow thats pretty big for me
Re: Some notes on starting to use Django
#100Some more Django recommendations from Frank Wiles of Revsys (Django consultancy): https://frankwiles.com/questions/starting-django-projects/ I'll add a few of my own: * Set up the project using uv * I name the django project "project"; so settings are project/settings.py, main urls are project/urls.py, etc * I always define a custom Django user model even if I don't need anything extra yet; easier to expand later * s…
There is a convention to create "foo_settings.py" for different environments next to "settings.py" and start it with "from .settings import *"
You'll still want something else for secrets, but this works well for everything else, including sane defaults with overrides (like DEBUG=False in the base and True in only the appropriate ones).