search

pypa / setuptools

Official project repository for the Setuptools build system
https://pypi.org/project/setuptools/
MIT License
2.49k stars 1.18k forks source link

[FR] Add a .gitignore file to egg-info, dist-info, dist and build directories #4658

Open pelson opened 1 week ago

pelson commented 1 week ago

What's the problem this feature will solve?

Presently, git users tend to configure their repositories to ignore generated files from setuptools. This is easy enough (and expressive enough) to do for people who know what they are doing. For novice users though, it is very easy to commit these generated files into a repository (due to ignorance or by accident).

Describe the solution you'd like

I propose that we change the default such that generated directories (build, dist, *.dist-info and *.egg-info) are ignored. This is not a re-hash of #2455 and https://github.com/pypa/setuptools/pull/1497#issuecomment-423323011) - I am proposing that we generate files in build/.gitignore (and the other directories in question) containing *.

There may be expert corner-cases where people actually want to commit these files. In that case, they would need to remove the .gitignore file manually.

This proposal does not contradict https://github.com/pypa/setuptools/pull/4453, where developers are recommended to put common (across multiple projects) .gitignore specific configuration into a common place (not every project). To quote @jaraco's very good article:

[The] .gitignore for a project should specify elements unique to that project and not elements peculiar to the language or system or user.

My proposal supports that position further - there will be less incentive for projects to add *.egg-info / *.dist-info into their project's .gitignore, and there is no work needed on the part of a developer to configure their git to handle Python/setuptools like projects.

This also aligns well with the approach taken in https://github.com/python/cpython/issues/83417.

Alternative Solutions

No response

Additional context

Some notes:

Code of Conduct

pelson commented 1 week ago

I'd be willing to do this, if accepted.

abravalheri commented 1 week ago

If the core devs are happy with this approach to only tackle git, I suppose it is also good for setuptools!

I would be happy with this change but I would like to see if @jaraco has any thoughts on this.

eli-schwartz commented 1 week ago

Meson has also done this for absolutely ages and we haven't gotten a single complaint, but have gotten lots of grateful users. (It is especially useful in the case of meson since it is routine for people to have multiple build directories rather than just build/ but even without that factor it's very useful.)

jaraco commented 6 days ago

This sounds reasonable to me. As pelson points out, this approach moves the concern more close to the relevant location in a systematic way.

I'm a little uncomfortable with the idea of embedding behaviors specific to a tool (git), acknowledging that it is a dominant de facto standard. It does seem more appropriate to teach more specialized tools about the more general ones than the other way around (e.g. teach setuptools about git instead of teaching git about setuptools).

I have no objections.