Turning versions and file finding on/off independently?

[ChrisBarker-NOAA]

IIUC, setuptools_scm does two things:

1. auto-generates a version from the SCM
2. 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.

[RonnyPfannschmidt]

File finding is always enabled due to setuptools Design mistakes

Versions finding is supposed to be always opt in,

[ChrisBarker-NOAA]

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.

[RonnyPfannschmidt]

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

[ChrisBarker-NOAA]

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.

[RonnyPfannschmidt]

Adding the tool.setuptools_scm section is the opt in

[RonnyPfannschmidt]

closing this as not actionable as setuptools_scm version finding is opt in and file finding is currently not controlled

[ChrisBarker-NOAA]

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.

[RonnyPfannschmidt]

@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

[ChrisBarker-NOAA]

Exactly -- if you use setuptool_scm to determine the files for the sdist, then it tried to build a version number from the scm.

This also happens in the command line when you try to test.

It's not out of the question 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.

[RonnyPfannschmidt]

what command do you run?

[ChrisBarker-NOAA]

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.

[RonnyPfannschmidt]

The cli command has no opt out as of now

The erro from the build step is needed

[ChrisBarker-NOAA]

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.