opt out file finders

[RonnyPfannschmidt]

followup to pypa/setuptools#2652
followup to #190

unfortunately people have to have setuptools_scm installed in their envs, and thus file finders are active even if they don't want them active

we should figure a local opt-out/in as workaround
a opt-in may be possible by adding well chosen global state

aka only working on folders we registered by a integration before

[jsallay]

I've read through the various issues on this subject and I just wanted to add a point that I haven't seen brought up. I first noticed this issue when I saw that my CI files were being added to the sdist. I also checked your releases and saw that the setuptools_scm .github folder is included in the sdist.

I worry about this from a security perspective because sometimes people hard-code secrets for CI. By including it in the sdist, they are now releasing their secrets with the package (even when creating the package from a non-public repo). I know that it would be better for people to NOT commit secrets to their repos. But it happens quite often and it isn't obvious to a package creator that those files will be included.

[allisonkarlitskaya]

To paraphrase a bit from #847: I really think this should be some kind of opt-in rather than an explicit opt-out. Every user of setuptools should not be expected to opt-out of every single plugin that they know (or don't know) about just in case it might be installed in their environment.

Two ideas for a low-barrier opt in, which (together?) would probably cover 90%+ of existing users:

• mention of setuptools_scm as a build dependency
• [tool.setuptools_scm] section in pyproject.toml, as is done for the version behaviour

That could then be coupled with an explicit opt-out for people who want the version behavior without the file disting behaviour.

[RonnyPfannschmidt]

Structurally this is a upstream issue with setuptools, a file finder is utterly blind and without context

Most recent setuptools versions are working on providing a new way to do this, but nobody so far tried to use that

I consider the secret leaking a strawman, any secret that's committed unencrypted to a git repo ough to be considered compromised

Im happy to accept contributions or to help anyone wanting to fix this in setuptools

I'm not going to try to fix this myself within the next 3-5 years

[con-f-use]

Btw. with build isolation in wide use, e.g. by pip, why would people have setuptools_scm installed in their project's Python environment these days. Even when installing in editable mode, most tools would build an editable wheel in isolation and install that . As a build dependency in the isolated build env, setuptools_scm gets automatically downloaded and when not building, I don't see why you'd need it. What am I missing?

I mean yes, it's still unexpected behavior that should be fixed, ideally upstream, as it's potentially every file-finder plugin, but still...

[daveware-nv]

This behavior is quite frustrating since the setuptools documentation points people at using setuptools_scm for getting version set from source control tags, but this then completely breaks the ability to exclude files from the build using pyproject.toml configuration:

[tool.setuptools.packages.find]
where = ["src"] 
exclude = ["mypackage.subpkg*"]

I've made some changes against v7.1.0 to make the find_files behavior opt-in

[tool.setuptools_scm]
enable_find_files = true

It (hopefully) would be easy enough to make it opt-out instead, I don't know which way around is the biggest pain point.

Unfortunately I notice that there has be some heavy refactoring in the main branch, so it certainly wont merge as-is, and I'm unclear on what the current status of things is in the main branch (so no idea if there is any point attempting at the moment)

Alternatively could a 7.1.x branch be made to put it there?

Anyway my branch can be found at https://github.com/daveware-nv/setuptools_scm/tree/make_find_files_opt_in

[RonnyPfannschmidt]

@daveware-nv please open a draft pr for reference, i intend to get a new release out within the next 2-4 weeks