Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix building from archived source code without .git #50

Open
C0rn3j opened this issue Oct 6, 2024 · 4 comments
Open

Fix building from archived source code without .git #50

C0rn3j opened this issue Oct 6, 2024 · 4 comments

Comments

@C0rn3j
Copy link
Owner

C0rn3j commented Oct 6, 2024

@git-developer Integrating setuptools-scm in #30 broke this.

We could disable the Assets generating the source builds and make everyone clone from git, but:

We could simply also hardcode a "unknown version from tarball" string or otherwise hardcode some version, but that might make supporting it a nightmare, it would break the daemon vs sc-controller version mismatch detection and possibly confuse the users too.

What we could do that'd possibly be a good solution is have the CI commit the calculated git version to the repo automatically?
But I am unsure how to do it in a way which would actually be up to date and not current version - 1.

I am blanking out on any other good solutions.

[0] % ./run.sh       
* Creating isolated environment: venv+pip...
* Installing packages in isolated environment:
  - setuptools-scm>=8.0
  - setuptools>=60
  - wheel
* Getting build dependencies for wheel...
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/pyproject_hooks/_in_process/_in_process.py", line 373, in <module>
    main()
  File "/usr/lib/python3.12/site-packages/pyproject_hooks/_in_process/_in_process.py", line 357, in main
    json_out["return_val"] = hook(**hook_input["kwargs"])
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/pyproject_hooks/_in_process/_in_process.py", line 134, in get_requires_for_build_wheel
    return hook(config_settings)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools/build_meta.py", line 332, in get_requires_for_build_wheel
    return self._get_build_requires(config_settings, requirements=[])
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools/build_meta.py", line 302, in _get_build_requires
    self.run_setup()
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools/build_meta.py", line 318, in run_setup
    exec(code, locals())
  File "<string>", line 45, in <module>
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools/__init__.py", line 117, in setup
    return distutils.core.setup(**attrs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools/_distutils/core.py", line 145, in setup
    _setup_distribution = dist = klass(attrs)
                                 ^^^^^^^^^^^^
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools/dist.py", line 283, in __init__
    _Distribution.__init__(self, dist_attrs)
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools/_distutils/dist.py", line 279, in __init__
    self.finalize_options()
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools/dist.py", line 635, in finalize_options
    ep(self)
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools_scm/_integration/setuptools.py", line 123, in infer_version
    _assign_version(dist, config)
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools_scm/_integration/setuptools.py", line 58, in _assign_version
    _version_missing(config)
  File "/tmp/build-env-58yivh01/lib/python3.12/site-packages/setuptools_scm/_get_version_impl.py", line 117, in _version_missing
    raise LookupError(
LookupError: setuptools-scm was unable to detect version for /home/c0rn3j/Downloads/sc-controller-0.4.9.5.

Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work.

For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj

ERROR Backend subprocess exited when trying to invoke get_requires_for_build_wheel
@git-developer
Copy link

OK, I see. That's a design problem. We decided to have a single source of truth, and this single source is Git now. So, if you download a tarball, that's not enough. From my point of view, we have to decide between

  1. Make Git a hard requirement for a build.
    • The sources are managed in Git, so it should at least be possible to every client to access it.
    • If building from tarball/zip is a requirement, this option is out.
  2. Move the single source of truth away from Git into a file.
    • The problem is, this file must be managed, for every branch. This must be done automatically somehow.

I think we don't want to create a second commit with an updated version number in the CI for each code change commit. Think of how the history would look like.

How do other projects solve this problem? Every user of setuptools-scm must be affected. Other projects I know actually use tarballs as archive only and always build from git.

@git-developer
Copy link

There seems to be an env variable SETUPTOOLS_SCM_PRETEND_VERSION_FOR_${PACKAGE_NAME} that might be used for non-git builds. But this doesn't help in finding an appropriate value. Is it maybe possible to add some file on creation of a a source tarball?

Idea: we could manually create a source zip in the CI including the version info.

@C0rn3j
Copy link
Owner Author

C0rn3j commented Oct 6, 2024

One thing we could do is detect lack of .git and try parsing the parent directory in that case - i.e. sc-controller-0.4.9.5.

@git-developer
Copy link

Good idea. AFAIK, this directory name should be composed of the project name and release version. So even branches / tags could be handled properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants