Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 task done
pelson opened this issue Sep 25, 2024 · 4 comments
Open
1 task done
Labels
enhancement Needs Triage Issues that need to be evaluated for severity and status.

Comments

@pelson
Copy link
Contributor

pelson commented Sep 25, 2024

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:

Code of Conduct

  • I agree to follow the PSF Code of Conduct
@pelson pelson added enhancement Needs Triage Issues that need to be evaluated for severity and status. labels Sep 25, 2024
@pelson
Copy link
Contributor Author

pelson commented Sep 25, 2024

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

@abravalheri
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

jaraco commented Sep 27, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Needs Triage Issues that need to be evaluated for severity and status.
Projects
None yet
Development

No branches or pull requests

4 participants