setuptools_scm
setuptools_scm copied to clipboard
Turning versions and file finding on/off independently?
IIUC, setuptools_scm does two things:
- auto-generates a version from the SCM
- generates a file list for the sdist from the SCM
But as far as I can tell, it always does both of these. There are times when one might want one or the other, but not both.
Is there a way to specify which of these functions you want in pyproject.toml? If not, where in the code would I go to add that?
NOTE: my use case is that I really want the file finding, but I have other ways to specify the version. I could probably just write the version to _version and ignore it, though it might overwrite it anyway in the metadata. But worse than that, right now my SCM is not set up right for setuptools_scm to generate the version (I think I don't have the right tags)
File "/Users/chris.barker/miniconda3/envs/gnome_build/lib/python3.10/site-packages/setuptools_scm/version.py", line 97, in tag_to_version
version = config.version_cls(version_str)
File "/Users/chris.barker/miniconda3/envs/gnome_build/lib/python3.10/site-packages/packaging/version.py", line 198, in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: 'v0.0.5sp'
Fine -- I have a tag that's incompatible with the version package -- but it then kills the whole process :-( So now I can't use the find_files, which is critical to my use case.
File finding is always enabled due to setuptools Design mistakes
Versions finding is supposed to be always opt in,
File finding is always enabled due to setuptools Design mistakes
But doesn't setuptools_scm have to plug itself into setuptools? wouldn't it simply not do that? Or is that done at module initialization?
Versions finding is supposed to be always opt in,
But it doesn't appear to be -- at least not with the command line tool:
python -m setuptools_scm ls
I get an error with the version finding.
Tugh looking now, I see that the intended use of that is: "Print project version according to SCM metadata"
so fair enough, though it would be nice to be able to get the file list on its own.
I thought I was having issues with the broken version finding in my actual build, but I'll poke into that again.
A setuptools plugin is part of the package
The file finder of that is always enabled
It's a nice idea to always try the ls
Versions finding is supposed to be always opt in,
If I put only:
[tool.setuptools_scm]
in pyproject.toml, then it may not USE the version when building the package, but it does run the version-detecting code, which then errors out if it doesn't work. which is a problem for me :-(
It's a nice idea to always try the ls
which also requires the version-detection to work :-(
It also doesn't respect the MANIFEST.in -- which I suppose is a setuptools thing, but too bad that I can't actually use that to test how an sdist will get built.
Adding the tool.setuptools_scm section is the opt in
closing this as not actionable as setuptools_scm version finding is opt in and file finding is currently not controlled
Actually, version finding is not (as of last time I tested it) opt-in -- actually using the version is opt-in, but it appears to use the SCM to try to calculate the version, whether to you want to use it or not -- so if your SCM is not set up in a compatible way, then it barfs out, even though you don't want to use the version.
It would be really nice it there were a way to not even try to figure out the version.
@ChrisBarker-NOAA unless there is a setuptools_scm section in pyproject.toml or a use_scm_version flag there shouldn't be any version determining, if there is thats a bug
Exactly -- if you use setuptool_scm to determine the files for the sdist, then it tried to build a version number from teh scm.
This also happens in the command line when you try to test.
It's not out of the quessiuon that I did something wrong, or it's been fixed since i tested it, but I really did try hard.
I can't do more testing now -- but see my original post.
If you can't replicate, I'll try to get you more info soon.
The trick is that you need to run it in a git project with invalid tags.
what command do you run?
Trying:
python -m setuptools_scm ls
i get:
Warning: could not use pyproject.toml, using default configuration.
Reason: [Errno 2] No such file or directory: '/Users/chrisbarker/Hazmat/GitLab/pygnome/pyproject.toml'.
/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/config.py:61: UserWarning: relative_to is expected to be a file, its the directory '.'
assuming the parent directory was passed
warnings.warn(
Traceback (most recent call last):
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/runpy.py", line 86, in _run_code
exec(code, run_globals)
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/__main__.py", line 6, in <module>
main()
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/_cli.py", line 35, in main
version = _get_version(config)
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/__init__.py", line 153, in _get_version
parsed_version = _do_parse(config)
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/__init__.py", line 100, in _do_parse
version = _version_from_entrypoints(config) or _version_from_entrypoints(
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/_entrypoints.py", line 66, in _version_from_entrypoints
version: ScmVersion | None = _call_entrypoint_fn(root, config, ep.load())
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/_entrypoints.py", line 40, in _call_entrypoint_fn
return fn(root, config=config)
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/git.py", line 181, in parse
return _git_parse_inner(
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/git.py", line 224, in _git_parse_inner
return meta(
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/version.py", line 226, in meta
parsed_version = _parse_tag(tag, preformatted, config)
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/version.py", line 202, in _parse_tag
version = tag_to_version(tag, config)
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/setuptools_scm/version.py", line 97, in tag_to_version
version = config.version_cls(version_str)
File "/Users/chrisbarker/miniconda3/envs/py3/lib/python3.10/site-packages/packaging/version.py", line 198, in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: 'v0.0.5sp'
And I get a similar error if I try to build the package.
It seems it's trying to create a version string , even though I haven't asked it to do that.
The cli command has no opt out as of now
The erro from the build step is needed
The cli command has no opt out as of now
That would be a great feature to have.
The erro from the build step is needed
But if I'm not going to use the versions string from VCS in my build, then it's not needed, but it does prevent me from using the file features, which is unfortunate.
so the feature request is for the cli to support file listing without version guessing
So the feature request is for the cli to support file listing without version guessing
yes.
And also for building and sdist with the file sekectiuon wihtout versionh guessing.
In short, I should be able to use the file selection features withou ANY version guiessing going on.
Ideally the other way around as well, but apparently setuptools doesn'st make that possible :-(
THanks!