django-environ VS cookiecutter-django

This Django Starter kit takes care of automated creation of virtual environment and installing of Python packages and setting up the database with bash scripts. In addition to PostgreSQL and TailwindCSS, all the sensitive values are taken care of in a .env file using django-environ package. The virtual environment is maintained using pip-tools.

I used to do this but recently switched to using environment variables and now prefer this approach. Essentially you keep the single settings.py file that is generated with startproject, and use os.environ or os.getenv to set certain settings. Check out the FeedHQ settings.py for an example. I use direnv to automatically set my environment variables on my local machine, but django-environ is a popular alternative.

Here i decided to use django-environ's env.db() for the DATABASE_URL.

You might want to use django-environ package for this issue. Create a .env file in the project folder and follow these steps.

For this i use django-environ. Here are a few basic settings:

You could also use just django-environ package to both import config from .env and set a database url instead of using 2 dependencies. I also think of a couple things I could add to the list, maybe I should a write a blog post as well?

You can use django-environ

Docker does not do any quote parsing. For this same env file, it will set the value of the variable to `"foo"` (retaining the doublequotes in the value).

Bash, of course, requires quotes if the variable contains any special bash characters (for example, literal JSON with curly brackets), but its quote handling is much more complex. django-environ doesn't interpret bash code; it just does simple quote chomping.

There's no reliable .env syntax you can use that works in all 3 of django-environ, Docker, and bash; and any variable that should start and end with quotes that are not stripped off can't be expressed in a way that both Docker and django-environ will read in the same way.

This may seem like a nit-picking edge case, but it's indicative of the design philosophy in django-environ of trying to be "helpful", but in ways which lead to subtle confusion. The way it guesses the path to your `.env` file is another example.

[1] https://github.com/joke2k/django-environ/blob/main/environ/e...

For Django use useful environ-wrapper: django-environ

Falco, in contrast to cookiecutter-django, aims to enhance the Django developer experience beyond project generation. It provides a CRUD generator and guides on various Django topics such as task queues, multitendency, deployment, realtime, etc.

It's not a tutorial but it's a resource to generate a Python+Django project with celery and Dockerfiles and other things you mentioned : https://github.com/cookiecutter/cookiecutter-django

There are very useful packages for bootstrapping your Django projects in minutes such as django-cookiecutter and djangox. If you are a seasoned developer I'd highly recommend using one of these instead of what I'm going to show here. But if you are struggling with the project structure of these packages as a beginner to intermediate Django developer and looking to structure your own Django projects in a better way, I have created a lightweight setup that deals with the basics of setting up a Django project with PostgreSQL as database and TailwindCSS as our styling library.

And so, the idea for cookiecutter-django-lite came into existence. I am an absolute fan of https://github.com/cookiecutter/cookiecutter-django - but for a lot of use cases this template is an overkill so I thought a barebones version of this will be superuseful - and that's how the idea of cookiecutter-django-lite was born.

Consider taking a look at cookiecutter to generate projects from templates. There is also cookiecutter-django. As for your environment variables you should have an example .env file containing all the environment variables required by your project (without setting them) that can be safely pushed into your repository for you and other developers to copy into the actual .env file that'll be used by your project (add this file to .gitignore)

I'm obviously biased, so take what I say with a grain of salt, but I also probably know more about this space than ~anyone else. I'd say that your characterization is pretty accurate. There are many similar products to Pegasus (you can find a pretty comprehensive list here: https://github.com/smirnov-am/awesome-saas-boilerplates) but most of them are either more focused on infrastructure/setup (e.g. cookiecutter-django or - as you noted - far less mature/maintained (most of the others on that list).

I followed a lot of the guidance found in this "template" here: https://github.com/cookiecutter/cookiecutter-django

If you understand all that and just want to get started as quickly as possible, use a project generator such as cookiecutter-django or API Bakery. Note that I'd avoid using these until you have a solid grasp of Django otherwise you'll have no idea what's going on.

Boilerplate is not in opposition to productivity. Especially when it’s all written for you, as it is in Django, Rails, etc. You can start with something like Cookiecutter Django.