When using a mono-repo with dependencies that are sub-directories, installation works fine, but when adding/removing deps, the resolution process fails because an internal dependency can't be found on PyPi. This happens because the source information isn't propagated correctly from the Provider.
This is admittedly a pretty niche issue for our project structure. As best as I can tell, the explicit nature of the repository isn't pulled into the _explicit_sources in the provider from the DirectoryPackage that actually holds the definition.
Workarounds
I was able to mitigate by modifying the source file directly for Provider, changing from this:
if explicit_source := self._explicit_sources.get(dependency.name) or package.source_reference:
This has the effect (as far as I can tell) that the source pulled from the lock file will always be respected, so I don't know if it's a valid long term fix.
Loading configuration file /home/Philip.Capel/.config/pypoetry/config.toml
Adding repository evozyne (https://pypi.dev.internal.tools) and setting it as explicit
Using virtualenv: /home/Philip.Capel/projects/mew/.venv
Updating dependencies
Resolving dependencies...
# redacted
Source (PyPI): Getting info for dep_that_breaks (0.4) from PyPI
[urllib3:urllib3.connectionpool] https://pypi.org:443 "GET /pypi/dep_that_breaks/0.4/json HTTP/11" 404 24
Falling back to installed packages to discover metadata for dep_that_breaks
Found 0 compatible packages for dep_that_breaks
1: Version solving took 0.500 seconds.
1: Tried 1 solutions.
there is no way to pass source information through standard metadata, it is expected that a parent project knows nothing about sources defined in a dependency.
Description
When using a mono-repo with dependencies that are sub-directories, installation works fine, but when adding/removing deps, the resolution process fails because an internal dependency can't be found on PyPi. This happens because the source information isn't propagated correctly from the
Provider
.This is admittedly a pretty niche issue for our project structure. As best as I can tell, the explicit nature of the repository isn't pulled into the
_explicit_sources
in the provider from theDirectoryPackage
that actually holds the definition.Workarounds
I was able to mitigate by modifying the source file directly for
Provider
, changing from this:https://github.com/python-poetry/poetry/blob/a74d3a79028535baf48073c969d327978d87d6c9/src/poetry/puzzle/provider.py#L708
To this:
This has the effect (as far as I can tell) that the source pulled from the lock file will always be respected, so I don't know if it's a valid long term fix.
Poetry Installation Method
other
Operating System
Ubuntu 22.04.4
Poetry Version
1.8.3
Poetry Configuration
Python Sysconfig
No response
Example pyproject.toml
You will need to have a mono-repo style project, where there is a top level package defined by the following:
Within the
some-sub-package
if you define the internal source and point to it explicitly in the dependency you could have something like:Poetry Runtime Logs