Description
The runtime resolver providers (PyPIProvider, GitHubTagProvider, GitLabTagProvider) conflate two responsibilities: finding which versions exist and deciding where to download from.
The override_download_url parameter leaks download concerns into the resolver, and the Candidate.url field is overloaded to carry the download location through from resolution to download.
Current behavior
The config-layer resolver classes (e.g. PyPIGitResolver) pass download-related information like override_download_url to the runtime resolver. The resolver stamps this URL onto Candidate.url during version resolution (see _find_candidates() in resolver.py). The download() method then blindly reads candidate.url with no logic of its own.
This means:
- The resolver decides where to download from, not just which versions exist
- Candidate.url means different things depending on the provider (PyPI sdist URL, git+https://... VCS URL, GitHub API tarball URL)
- The download() methods on the config-layer classes are trivial one-liners because the resolver already did the download-related work
- Adding a new download strategy requires modifying the resolver, even if resolution logic doesn't change
Expected behavior
Resolution and download should have clear boundaries:
- Resolver returns version candidates (name, version, upload_time, remote_tag, etc.) but not the download URL
- Downloader constructs the download URL from its own config and the resolved version
- Candidate is not overloaded as a URL carrier between the two phases
Context
The current design is historical, override_download_url existed on the runtime providers before the new source config layer (_resolver.py) was built. The config layer was designed to reuse the existing runtime providers but it carries the coupling forward.
Description
The runtime resolver providers (PyPIProvider, GitHubTagProvider, GitLabTagProvider) conflate two responsibilities: finding which versions exist and deciding where to download from.
The override_download_url parameter leaks download concerns into the
resolver, and theCandidate.urlfield is overloaded to carry the download location through from resolution to download.Current behavior
The config-layer resolver classes (e.g. PyPIGitResolver) pass download-related information like override_download_url to the runtime resolver. The resolver stamps this URL onto Candidate.url during version resolution (see _find_candidates() in resolver.py). The download() method then blindly reads candidate.url with no logic of its own.
This means:
Expected behavior
Resolution and download should have clear boundaries:
Context
The current design is historical, override_download_url existed on the runtime providers before the new source config layer (_resolver.py) was built. The config layer was designed to reuse the existing runtime providers but it carries the coupling forward.