1. 25

  2. 5

    These are good suggestions.

    I’ve often felt in my career like Django is misused. It’s nice to see a Django article which doesn’t immediately attempt to do something far beyond Django’s ambit, but instead directly addresses common Django shortcomings. Even plain news sites written with Django could use this advice.

    1. 2

      Thanks Corbin. I tried to keep this as simple as possible and strictly to things that I would do even for a tiny little side project. The post started from me making a bunch of notes (and looking at my shell history) after starting a couple of small projects in quick succession.

    2. 3

      Sensible suggestions! In terms of 12factor apps I feel like (something like) https://github.com/joke2k/django-environ is also essential nowadays.

      1. 2

        It’s a great suggestion! I haven’t used django-environ for a while on side projects, but I should look into it again (I remember using it on a commercial project a while ago, and thinking that it was great).

        Just looking at some recent code of mine, I’ve ended up using this pattern a few times which I think achieves a similar result:

        SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY")
        if not SECRET_KEY:
            raise ImproperlyConfigured("Do not run with the default secret key in production")

        The added support for cache / email “url” formats in django-environ and the ability to replace dj-database-url as a dependency definitely makes me want to use this on my next project.

      2. 2

        Good suggestions. Though the curmudgeon in me says, “why doesn’t django do this by default?”

        I was quite happy when I realized that cargo would create a .gitignore file for me by default when it detected a .git repo, and same for .hgignore. On the one hand it’s kinda extra complexity tucked into an odd spot… on the other it now makes me very much aware of when a tool doesn’t do that.


          Though the curmudgeon in me says, “why doesn’t django do this by default?”

          In order:

          1. Because there’s no simple cross-platform way (remember, people will develop on Windows!) to automatically set the env variable locally for a new project. There’s really not even a good way if you just restrict yourself to Unix-y systems, because any approach you take, like buying into direnv or whatever, will cause screaming rage from some subset of users who think that approach is evil and wrong and must never be used.
          2. Similar to (1) because really this is about being able to set a single value in the env and then parse it out into all the config Django wants for the database. Django also has to support setting a lot of DB config that doesn’t easily fit into a simple URL.
          3. It’s a massive backwards-compatibility headache to change the default user-model approach. Fixing this would basically require complete deprecation and replacement of the current django.contrib.auth, which is such a huge disruptive change that it’s unlikely ever to happen. Though pressure to support modern MFA and/or hardware-token-based auth protocols may end up forcing Django’s hand on massive backwards-incompatible changes in the auth app.
          4. This is entirely a matter of subjective taste and would be bikeshedded to death if Django tried to do it for you.
          5. Same as (4).
          6. Patches welcome.

          (and an obligatory reminder that although I have in the past held leadership positions within both the Django open-source project and the nonprofit foundation which supports it, I stepped down from all of them a couple years ago and am now merely someone with a lot of experience in Django, rather than someone who makes or can speak for the technical decisions of the project; thus, the above are my own personal answers and do not necessarily represent any official stance of the Django technical board)


            Thanks for the info.

        2. 2

          gibo, mentioned in the post, is pretty cool. It dumps GitHub’s recommended .gitignore file contents out, so you can kickstart a .gitignore for a new project.

          1. 2

            ❤️ gibo.

            It’s one to the shell utilities that I install when I set up a new development box. For this post I went with the curl since it’s Python specific and an easy copy/paste. The reality is that I end up typing gibo dump Python more often that ctrl+r /gitignore.

            1. 2

              There’s also gitignore.io which allows combining and discovering different ignores