Live data from Hacker News

Some notes on starting to use Django

jvns.ca

91–100 of 145 posts

Re: Some notes on starting to use Django

#91
post #24

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.

is this like the "it takes 50 hours to set up a project management tool to work the way you want"? what happens if you onboard a superstar that works with django some other way?

Re: Some notes on starting to use Django

#93

Earlier 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.

The point is that companies don't actually know what consumers want so a volume / meandering approach is required

Re: Some notes on starting to use Django

#94
post #83
post #73

Some 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.

That's something that python-dotenv enables. It can pull from environment, which you can wire up from k8s secrets or whatever is the case for your hosting.

Re: Some notes on starting to use Django

#95
post #53

Earlier 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…

What a crazy design, why don't they just do pre1 do1 post1 pre2 do2 post2?

Re: Some notes on starting to use Django

#96
post #27

The 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…

Not really, unfortunately. The thing is, if you mistype a configuration key, Django won’t pick it up. It’ll just leave the default value in place. I also don’t think it does any validation on settings values, it’ll just pass them to whatever uses them. That’s the last time I used it anyway.

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

#97

For 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)

I agree with many -if not all- of these. Thank you for collecting them. These can be readily converted into a SKILL.md.

Re: Some notes on starting to use Django

#99
post #81

Earlier 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.

In the default shell? I've definitely started new django projects since 2023 and I seem to remember always having to use shell_plus for that, though maybe thats just become something I automatically add without thinking

Edit: Yep, you're right, wow thats pretty big for me

Re: Some notes on starting to use Django

#100
post #73

Some 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…

> * settings.py actually conflates project config (Django apps, middleware, etc) and instance/environment config (Database access, storages, email, auth...); I hardcode the project config (since that doesn't change between environemnts) and use python-dotenv to pull settings from environment / .env; I document all such configurable vars in .env.example, and the defaults are sane for local/dev setup (such as DEBUG=true, SQLIte database, ALLOWED_HOSTS=*, and a randomly-generated SECRET_KEY); oh and I use dj-database-url to use DATABASE_URL (defaults to sqlite:///sqlite.db)

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).

Post reply on HN