setuptools_scm
setuptools_scm copied to clipboard
pypa
opt out file finders
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
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.
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_scmas a build dependency -
[tool.setuptools_scm]section inpyproject.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.
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
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...
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
@daveware-nv please open a draft pr for reference, i intend to get a new release out within the next 2-4 weeks