Remove .gitignore

[jaraco]

The presence of a .gitignore file only contradicts the documented strategy. With this file removed, even after running tests, git reports "working tree clean" in my environment. There's no need for the .gitignore.

Users have a couple of options for ignoring artifacts as documented in that (now updated) strategy:

1. Configure global ignores that cover the concerns.
2. Configure per checkout ignores in .git/info/excludes.

[jaraco]

@Avasam What do you think of this approach instead of #4325?

[Avasam]

I personally have two concerns in flat-out removing the .gitignore file:

1. It's likely going to be the first point of contact for any newer contributor annoyed by extra files appearing in their git changes. Unless it causes issues, an empty .gitignore with a comment linking to your documentation as to why it is empty and should be kept empty is better imo.
2. I was quite offput being told to add and maintain an out-of-project configuration file, and change global git configs, for a single project.
   The documented solution also conflicts with other projects staging some editor configurations for example: In setuptools I should ignore all editor configurations (vscode, pycharm, other), but other projects do provide project-specific configurations (like extensions, default formatters, project-specific layout information, etc.).
   That's actually an easy solve using ./.git/info/exclude as I found here: Fix all mypy issues #3979 (comment) but I don't think there's any mention of that option at https://blog.jaraco.com/skeleton/#ignoring-artifacts

Other than that (which are more documentation concerns), I think this approach is fine as it works for pypa / jaraco repositories/ecosystem, and contributors should have a few documented and easily accessible options of dealing with it the way that suits them best.

[jaraco]

2. I was quite offput being told to add and maintain an out-of-project configuration file, and change global git configs, for a single project.

That's fair, and thanks for sharing.

I realize it's "for a single project", but I observe you are already contributing to at least two projects affected by this issue (setuptools and distutils). I suspect, however, that you may also have interest in supporting some of setuptools' dependencies, several of which also follow the skeleton philosophy.

Moreover, the philosophy extends beyond skeleton-based projects, as it adds value for any new project or any project that's underconfigured for ignores.

2. [Project-specific configs is] actually an easy solve using ./.git/info/exclude

The git ignore docs mention .git/info/exclude to be used for "patterns which are specific to a particular repository but which do not need to be shared with related repositories", so it's really not appropriate for the purpose at hand. The purpose I'm after is to supply reasonable defaults that essentially apply to most projects and most machines for most users (ideally with the ability to override). .git/info/exclude only applies at the scope of a user+machine+repo combo. If you have 20 users (Setuptools has more) and 1.2 machines per user and 100 repos, that's 240 places where you need to supply this config.

Git doesn't provide a good config scope for this purpose. They have global (typically per-user config), system (per machine config), and local (per repo config). There's no good way to specify config that's shared across repos and users and machines.

That's why the motivations are documented (and linked from the README by way of the skeleton badge, albeit subtle).

2. I don't think there's any mention of that option at https://blog.jaraco.com/skeleton/#ignoring-artifacts

Good point. I'm always willing to improve the docs. I think using .git/info/exclude is an excellent suggestion for users who are only incidentally involved with skeleton-based projects. In jaraco/skeleton@8048318, I've updated the docs accordingly.

2. other projects do provide project-specific configurations (like extensions, default formatters, project-specific layout information, etc.).

I have only once run into a situation where the cross-repo concerns caused problems (pypa/build#518) and it was easily worked-around by overriding locally. In a situation where a project is specifically looking to track a file that's commonly ignored, I'd consider explicitly including in the .gitignore. In my experience, that's been rare, but I can see how it might happen more often under a different philosophy.

1. It's likely going to be the first point of contact for any newer contributor annoyed by extra files appearing in their git changes. Unless it causes issues, an empty .gitignore with a comment linking to your documentation as to why it is empty and should be kept empty is better imo.

While I agree it would be nice provide guidance where the user would stumble on it easily, it also means adding yet another static file to the boilerplate. Moreover, it implies that there should be more comments across each and every file in the skeleton pointing back to the skeleton guidance (e.g. .github/workflows/main.yml might point to one section, pyproject.toml might point to another section, a comment in mypy.ini, and so on). This proliferation of guidance quickly becomes unwieldy. Ultimately, I've settled on (a) providing a prominent badge in the readme and PyPI homepage that links to the guidance and (b) directing users to the guidance as needed. Ultimately, I have ambitions to remove all boilerplate, such that all cross-project concerns are managed outside of a project's repo.

Nevertheless, I am tempted by the idea of adding a link in the .gitignore just because there is so much inertia around managing these files.

For now, I'm unconvinced, but if the pressure increases, I'll likely capitulate and expand the guidance (in skeleton, not here).

I believe updating the docs and providing the per-checkout escape hatch should address the concerns and now I'm a lot more emboldened to proceed with this PR as proposed.

@Avasam Do you concur?

[Avasam]

Nevertheless, I am tempted by the idea of adding a link in the .gitignore just because there is so much inertia around managing these files.

For now, I'm unconvinced, but if the pressure increases, I'll likely capitulate and expand the guidance (in skeleton, not here).

At the end of the day, maintainers are the one that would have to deal with any increased contributor guidance/support, not I. And as you said, the door is open to increase documented guidance if you feel the need for it. So the ball's really all in your camp there :)

---

We seem to agree that the global gitignore is a good way to tackle a shared concern across multiple repos, and works for jaraco/skeleton based projects. With .git/info/exclude as an escape hatch when a project not related to this ecosystem somehow needs to include something. Or to avoid touching globals at all if the contributor so chooses. (for example I wouldn't put .vscode or .idea in my globals)

---

I believe updating the docs and providing the per-checkout escape hatch should address the concerns [...]

So do I. Thanks for this discussion!

[jaraco]

@abravalheri I'm merging now, but let me know if this causes you any consternation and the updated guidance doesn't provide a satisfactory solution.

[lazka]

I'd like to add that the missing .gitignore makes the file search in vscode hard to use as it includes all .pyc files too.

[Avasam]

I'd like to add that the missing .gitignore makes the file search in vscode hard to use as it includes all .pyc files too.

@lazka in your user configs, or the project's .vscode/settings.json, you can add:

    "search.exclude": {
        "*.pyc": true,
    },

As a more general comment, it does mean any tool that was using .gitignore to ignore folder, generated files, etc., must be configured explicitly to ignore them. (for example if they don't automatically ignore venvs)