Repository navigation
Wire source_resolver into resolver and download pipelines #1048
Description
PR #938 defines a model layer for declarative source configuration with provider classes, a RetrieveMethod enum, and discriminated union dispatch. This issue tracks wiring that model layer into the runtime so YAML-configured providers are used by the resolver and download pipelines.
Work items:
- Modify
default_resolver_provider()inresolver.pyto checkpbi.source_resolverbefore returningPyPIProvider - Modify
default_download_source()insources.pyto detectgit+https:///git+ssh://URLs and route to the git clone path - Add
remove_dot_gitfield toGitOptions - Connect
git_options(submodules, submodule_paths, remove_dot_git) to the git clone download path
Plugin precedence is preserved — overrides.find_and_invoke() calls the plugin hook first. The source_resolver check only runs when no plugin exists.
Activity
tiran commentedon Apr 13, 2026
Your ticket is a couple steps ahead. First the proposal needs to be approved. Next I'll update and push my configuration scaffolding. Then we can implement the logic and integrate it with the rest.
LalatenduMohanty commentedon May 18, 2026
The proposal #938 has merged. We are waiting for #1052 to land and then we can work on this issue.
smoparth commentedon Jun 22, 2026
After adding remove_dot_git field to GitOptions with default to True, caused .git to be removed after all git clones, including existing req.url flows. With .git removed, setuptools-scm cannot determine the version and fall back to 0.0.0, causing wrong version appended to package names ex: stevedore-0.0.0.tar.gz '0.0.0' over public version '5.2.0'.
For backward compatibility defaulted
remove_dot_gitto Falsefeat(resolver): wire source_resolver into resolver and download pipel…
smoparth commentedon Jun 22, 2026
Adding some notes for reference
Many Python packages use a tool called setuptools-scm to automatically determine their version number. Instead of hardcoding version = "5.2.0" in pyproject.toml, they write:
[tool.setuptools_scm]
And setuptools-scm figures out the version by looking at git tags. It checks two sources, in order:
The .git directory, it runs git describe --tags to find the nearest tag
A .git_archival.txt file, a fallback text file that records the tag/commit info
When you clone a repo and build it normally, .git exists, setuptools-scm reads the tags, and produces the correct version like 5.2.0.
What happens with our remove_dot_git: true:
Fromager clones stevedore at tag 5.2.0
Our code removes .git (because remove_dot_git: true)
Build step runs, setuptools-scm tries to find the version
No .git directory -- can't run git describe
No .git_archival.txt file either -- nothing to fall back to
setuptools-scm gives up and returns 0.0.0
The built sdist is named stevedore-0.0.0.tar.gz
Fromager's validation says: "expected 5.2.0, got 0.0.0" -- crash
This is exactly what broke the CI in PR #1202.
The fix: After removing .git, write a .git_archival.txt file that tells setuptools-scm what the version is. The file looks like this:
node: abc123def456...
node-date: 2026-06-22T10:00:00+00:00
describe-name: v5.2.0
ref-names: tag: v5.2.0
setuptools-scm reads this file, sees describe-name: v5.2.0, and correctly produces version 5.2.0.
Why it's tricky: At the point where we remove .git, we need to know the tag name and commit hash. The resolver already has this info (the Candidate object has remote_tag="v5.2.0" and remote_commit="abc123..."), but this info isn't passed down to download_git_source(). That plumbing needs to be added.
Without .git_archival.txt generation, removing .git is unsafe. So we keep .git by default until this issue is resolved.
feat(resolver): wire source_resolver into resolver and download pipel…
feat(resolver): wire source_resolver into resolver and download pipel…
feat(resolver): wire source_resolver into resolver and download pipel…
smoparth commentedon Jul 28, 2026
As discussed in Fromager office hours, closing this and will work on the feature branch created for this.