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

7988 fix resolving subdependencies from explicit source #7992

Closed
wants to merge 2 commits into from
Closed

7988 fix resolving subdependencies from explicit source #7992

wants to merge 2 commits into from

Conversation

b-kamphorst
Copy link
Contributor

Pull Request Check List

Resolves: #7988

  • Added tests for changed code.
  • Updated documentation for changed code.

@b-kamphorst
Copy link
Contributor Author

b-kamphorst commented May 23, 2023

Tagging @dimbleby for his involvement in https://github.com/orgs/python-poetry/discussions/7988.

Tagging @radoering for his involvement in #7658, #6879, and #7801 -- my guess is that you might be familiar with the downloading of packages and might be interested specifically in https://github.com/orgs/python-poetry/discussions/7988#discussioncomment-5981635.

My best guess at this point is that the issue is caused by the following elements:

  1. a Package instantiated by PyPiRepository is unaware of its source (e.g. Package.source_type and Package.source_reference are both None);
  2. a Package derived from a Dependency through RepositoryPool.find_packages(dependency) is (therefore also) unaware of its source -- even if that source is explicitly requested in Dependency.source_reference;
  3. the Chooser performs some fuzzy logic to get the links to a package. It appears to be impossible for that logic to have access to an explicit source. As I understand now, the Chooser:
    • tries to extract a package source_reference ONLY IF a source_type is provided (as stated, both are None if the source is a PyPiRepository);
    • if it fails, grabs the pypi repository regardless of other sources that are defined or the priority of the pypi repository;
    • if that fails yet again, grabs the first repository returned by RepositoryPool.repositories (can never have Priority.EXPLICIT).

This line of reasoning explains why the puzzle is solved successfully (uses VersionSolver._dependency_cache.search_for(dependency,...) and therefore maintains source information). It would also explain why PyPI is searched. It does not explain why the supplemental source (or any non-PyPI repo) is searched successfully as this repository seems to be ignored by the Chooser as well. Therefore I must be missing something still. Looking forward to your thoughts.

@dimbleby
Copy link
Contributor

do we even have a repro at this point?

The discussion seems to be about locking rather than installing, it doesnt look as though anything should get as far as the Chooser.

I would recommend a healthy degree of scepticism about whether what is being claimed is actually the case - folk misreport their misunderstandings on this tracker all the time. If you have made a good conscience best effort to reproduce and not managed it, you can go back and ask for a better reproduction.

@b-kamphorst b-kamphorst closed this by deleting the head repository May 26, 2023
Copy link

github-actions bot commented Mar 3, 2024

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants