setuptools_scm
setuptools_scm copied to clipboard
setuptools_scm tries to create archive of outer git repository
When setuptools_scm is used and packed python module comes not from git repository, but from usual archive, and build is happening inside other (outer) git repository, file_finder_git.py tries to create git archive of outer repository. This happens with latest setuptools_scm.
The following workaround seems to work for us https://github.com/OpenIndiana/oi-userland/pull/5194 . But it's not the real fix, as we just check that top-level repository is not setup.py-based.
@pawamoy thanks for the reference, i wonder if a managed global to inform the hook of the correct expected toplevel would sort this out nicely
Looking for setup.py (or pyproject.toml) to find the root is not sufficient, because there might be symlinks to somewhere else above setup.py but still in the same source repo.
That said I think a setup.py designed to work with the scm file finder cannot work with a source archive? It should work with a sdist though, I don't remember exactly the details right now.
bythat i meant that in the setup call/integration we set the expected scm root based on the input data and use it to ensure the file finder does not step out of the overall file tree
this will basically be a tactical "monkeypatch"
note that the file finder typically work with the sdist, but the git folder finding is missaligned due to the lack of extra information
@pawamoy thanks for the reference, i wonder if a managed global to inform the hook of the correct expected toplevel would sort this out nicely
Isn't this what root option is for? Or is that only used for version detection and not file-finding (not sure how that works exactly yet, though)?
(Off-topic: you're mentioning the wrong user :sweat_smile: @pawamoy instead of @pyhalov I guess)
@matthijskooijman file finders do not have access to that metadata CC @jaraco for the setuptools side
I can take a look, but can you create a reproducer for the issue? Is there a way you could avoid expanding sdists into the git repo to bypass the issue?
probably, but not soon