So what i was thinking is, how about django provides a base structure .gitignore file by default when a django project is initiated.
So when we write
django-admin startproject <name>
Project files are build, and with that a .gitignore with some obvious to be ignored files are listed over there in the root directory (like sqlite, pycache etc)
It’s just a idea i had, obviously making .gitignore files is not a hard task, but it would be great if it is present from the beginning when the project was initialised.
I see some other popular frameworks also has by default .gitignore files.
To be honest, I’ve never found the arguments in those links particularly convincing. One of the great things about Django that I think really helped it take off initially was its pragmatism about choosing good defaults that suited a lot of people’s use cases, and it feels like somewhere along the way that got replaced with an idea that Django must never make such choices because there will be some people who don’t like Django’s default.
The current default startproject template is, frankly, pretty bad from the perspective of both general good development practices and general good Django-usage practices. Getting better defaults – including pragmatic choices like a default .gitignore – would, I think, be a big boon for Django’s future, and I think it really ought to be properly discussed and considered rather than have the door immediately slammed shut because once upon a time the suggestion was rejected.
I don’t have a strong opinion on this particular issue, but if we cannot reference past discussions (this one less than two years ago) when a topic is re-raised, we could end up rediscussing an awful lot. What are your thoughts about this generally (how we make decisions)? Besides disagreeing with the conclusion, did you find something improper about the last discussion? (or was it just my linking to that discussion that was improper?)
There’s been a lot of discussion lately that Django is unfriendly to people making suggestions, and that mostly the experience is one of getting immediately shut down. If I put myself in the shoes of a newcomer, I’d feel like I’d just been told that the suggestion is permanently rejected and it’s bad to bring it up.
Meanwhile, the linked discussion is… well, I’d call it inconclusive at best. Adam and Mariusz were strongly -1, of course, but they weren’t the only participants in the thread and it mostly seems the thread died out because nobody was willing to stand up against strong opinions from a couple of well-known figures in the Django project, rather than because their arguments actually convincingly carried the day.
So I would say as a general guideline maybe it’s possible to be more gentle and cautious about rejecting things out of hand with “this has been discussed before” – especially since, for a project of Django’s size and age, practically everything has been discussed before at least once – and in this specific case I don’t see that there was a clear consensus to reject the suggestion in the earlier discussion, so it’s fair game to be brought up again.
And for what it’s worth, I think it’s a good suggestion, and I wish Django would adopt it so I could stop having to write alternate project templates that make the pragmatic default choices Django refuses to.
I also think this is a good idea and worth considering, but I mostly wanted to say that I agree with everything @ubernostrum said about the discussions that start and die here on the forums. After having read through the previous discussions on this, I also remain unconvinced by the arguments against this idea. There was a similar discussion recently about adding a pyproject.toml file, and a couple of strong “No!” opinions seemed to kill that idea too without further debate.
For what it’s worth, I’ve jumped on the uv train and start all my Django projects with uv init and then uv add django. Before you’ve even used the django-admin command, uv has already created a pyproject.toml file, a README.md file, and a .gitignore file. The .gitignore file only has the following contents:
For me, I’m happy with this workflow, but for others that don’t use uv, I can’t see why the startproject command couldn’t also add a .gitignore file to help its users (and also a pyproject.toml - but that’s another discussion!) There’s no need to have IDE-specific excludes in this file, we just need the bare minimum to help users start a new project following best practices.
As a participant in that past thread I just wanted to vocalize my continued support for this idea. And also I agree completely with @ubernostrum 's perspective on contributions. This remains one of the most obvious (to me) little things we could do that is beneficial to the overwhelming majority of people starting projects with very little downside.
Having more fully featured examples with a .gitignore (and, from the thread on the Django-admin command, e.g. a pyproject.toml, say) should be something we can unlock. (I’m more interested in examples with less files personally, but I see the tension goes both ways.)
Feedback on the PR there would be awesome!
FWIW Past arguments aren’t necessarily compelling but I do appreciate Tim’s linking back to past discussions — we do go round in circles without that. It can be hard to reconstruct every point, and recall why the status quo is as it is.
Thanks for the ping. Two concerns, neither of which are terminal. I’m roughly -0/+1 on this, as in, -0 to add to the current startproject template, +1 to add to at least one template if we end up creating a new command.
Not everyone uses git. However it’s by far the most popular and good to encourage the use of VCS generally.
At some point we have to draw a line and not turn too much into cookiecutter (unless we really want to).
One thing I would want is for this to be as minimal as possible. Right now I’m thinking:
__pycache__/
*.mo
.coverage*
A file as small as this is possible these days because there is a trend for tools to move their generated files into directories with a .gitignore in them.
We could think about adding e.g. dist/*, *.egg-info/* but I’m not sure most people are packaging their projects.
While it feels quite project-settings-method spesific, I would really want to have .env in gitignore as well, primarily to protect users from themselves.
I assume you could add both as commented out “suggestions” in a .gitignore, with a short explanation of when/why it should be uncommented.
I’m for this but only when / if Django either starts handling environment based settings or makes a strong suggestion to do this using one of the packages that reads .env files.
As already mentioned by others, I don’t think it will happen for startproject but it would be a great addition to @tom 's DEP for a new command.
I don’t see reasons to keep it minimal though, looking at other frameworks’s generated .gitignore they tend to include a lot, probably things for editors or tools I don’t use. It has never bothered me and it’s not really like this will require much maintenance “because vim is suddenly going to change the way they name temporary files”.
As far as adding .venv is concerned, I think we can go with sensible defaults, maybe just .venv or also venv. It would make sense to me that people who have their virtualenv inside the project directory and named otherwise represent a minority and also know they are doing something custom but I might be overlooking some specific tools or plateform?
As for the tangent on this thread:
I have to strongly agree with @ubernostrum with the need to stop slamming doors in people’s faces, as if only to try to be polite and courteous. The Django community brands itself as being welcoming. Telling someone who comes with a valid (ie: almost every other framework does it) idea that “we said multiple times we won’t do it” is far from being welcoming. Something along the lines of “Hey, if you missed those, here are a couple links to threads about the topic that could bring context here” could already sound nicer?
I also agree with @carltongibson that the context is useful but could we come up with a way, as a community, to provide this context in a less passive-aggressive way? If it’s too hard for humans, is there a way we could automate this? (hey bot, link to thread 1234)
On top of that, I want to say that, IMHO, if someone raises something that has been closed multiple times already, the failing probably doesn’t lie with the person raising this for the humpteenth time but most likely with the fact it has been closed in the first place while it is clearly something the community wants/needs. It could very well have been closed because “it was too early then”, which is still a good reason to re-visit the topic.
I will give my reasons, though I am not overly attached to any of them.
I’m a bit wary of the maintenance burden. Everyone will want to add their favourite editor. We will probably need to divide the file up into sections, which then puts an added burden on how it should be split up, what goes where. IMO the right place for files generated by specific OSes and IDEs is in that user’s global gitignore. Otherwise we’re also adding .DS_Store and all the rest.
We have already made the decision to not allow changes like this into Django’s .gitignore, which remains quite minimal (and could be reduced further I believe as some tooling has changed in the meantime) and I don’t think we should impose this burden on our users either. I worry that adding a confusing list of patterns adds more things a user feels they need to understand before they can just start writing code.
There is also a problem with blanket adding .idea/ and .vscode/ and so on. In many projects, these files should be in version control, as they are project specific. However, some places (such as my work) don’t like to add these and rather people maintain their own. In other jobs I’ve had, we have had specific files included from the .vscode/ for tricky bits of configuration, often for debugging. I don’t think there is a one size fits all solution here, so I’d rather omit it and let people set it up for their project (or the user’s global gitignore) however they feel is appropriate.
.venv and so should not be necessary as modern tooling adds a .gitignore into the folder driectly. .env on the other hand feels more useful as there are a lot of people out there using django-environ, python-dotenv and so.
Controversial as it may be, I try to avoid putting things in a global .gitignore, because I want the best possible experience for a new user in my project, and if I ignore it globally, they’ll run into trouble that I do not, not because I’m not aware of their unique challenges, but because I handled them only for myself.
I’d agree with the sentiment that editor configuration may not be easy to have a default gitignore specified, because some files should be included. In fact, I’d say most user projects probably should include them in their repositories.
There are a bunch of standard caches that we could default gitignore, like for coverage, pytest, tox, etc.
.venv isn’t needed with modern tools, but I think it’s probably wisest to go ahead and keep that in place to handle the cases where it isn’t included automatically. We can remove it when Django no longer supports versions of Python that don’t include the .gitignore in new venvs.
Pytest and coverage both have directory level .gitignores already. Tox doesn’t but has an accepted issue for it. If we added it we’d just have to remove it again later. I also don’t think many user projects use tox anymore, I only really see it used in old libraries. Packaging and testing is changing quite rapidly at the moment and I don’t want to try to predict winners in this space.
The exception here is the .coverage and .coverage.foo files which I did suggest adding.
I’m similarly not convinced it’s worth adding just to remove it again. In my view we should also be encouraging projects to use the latest version of Python. Since this only affects new projects, I see no reason to add it. If you’re going to make a decision to use an older version of Python (<3.13 in our case, which, by the earliest time this will be shipped, for Django 6.0, will already not be the latest version of Python), then you should also know enough to add your venv to .gitignore yourself, if you are also not using e.g. uv. I just don’t think it’s worth it.
There are several different opinions on this matter, and it seems we need to reach a consensus for the next phase of development. Do the steering council have an opinion on this? @steering_council
