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

[pelson]

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 #1497 (comment)) - 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 #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 python/cpython#83417.

Alternative Solutions

No response

Additional context

Some notes:

• We could now remove some of the guidance in https://github.com/pypa/setuptools/pull/4201/files related to .gitignore.

Code of Conduct

• I agree to follow the PSF Code of Conduct

[pelson]

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

[abravalheri]

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]

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]

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.