Closed bmitc closed 1 week ago
Resolution still has to happen (how else should the lock file be created?)
Please close
Why does resolution have to happen when the dependency does not apply to the given platform?
What is the point of environment markers then?
Also, if you're not a maintainer, then please don't suggest to close this.
This is an issue and a scenario that Poetry needs to handle, whether it's considered a bug or a feature request.
Why does resolution have to happen when the dependency does not apply to the given platform?
we already did this. How else should the lock file be created?
You can lock on a platform where the path is available and then install using that lockfile. Or you can just pip install
all along
This should be closed because it is working correctly, and as intended.
How else should the lock file be created?
Please elaborate. What is the lock file doing in this scenario?
You can lock on a platform where the path is available and then install using that lockfile.
I had in fact already created the lock file on Linux where that path existed. This issue was discovered when I went to add the Windows-specific dependency.
poetry builds a cross-platform lockfile to make sure that your requirements are consistent, and that your installation is reproducible. When doing that the platform on which you are executing the command is more or less irrelevant: it is a cross-platform lockfile so poetry has to consider requirements for all platforms.
So if your lockfile is out of date - eg because you are adding a new requirement - then poetry must rebuild it, and to do that it must be able to find all dependencies.
There is no bug here.
You keep referring to implementation details in order to reject a high-level use case.
In this scenario, it appears that the path
and markers
dependency keys are incompatible. This should either work as is and is thus a bug, is a feature request, or it is a documentation issue.
You stating that this isn't a bug over and over isn't contributing anything or helpful.
And it is not clear as to why Poetry needs to rebuild or re-resolve the path
and markers
specified dependency. Its lock component has no reason to be updated.
You stating that this isn't a bug over and over isn't contributing anything or helpful.
Nevertheless: it isn't! And will surely be closed as such sooner or later.
Documentation contributions are usually relatively straightforward and welcome. If you would like to see change happen then the most likely way to do that would be to submit a merge request clarifying whatever part of the docs you looked at and which did not help you to understand poetry behaviour.
Documentation contributions are usually relatively straightforward and welcome. If you would like to see change happen then the most likely way to do that would be to submit a merge request clarifying whatever part of the docs you looked at and which did not help you to understand poetry behaviour.
This is obvious. I would be happy to contribute a documentation change, but the point of this is to discuss the nuances of this issue. Even if it happens to be a documentation issue, which information hasn't been presented to convince of that, then this issue should remain open until the documentation is updated.
If you would like to contribute improved documentation then you can just go ahead and do it, no need for an issue too.
However it is true that those with the power to tidy up do seem content to allow the pile of unloved issues to accumulate...
Hopefully my last but one is most of the content you'd need.
I will close this issue because as already mentioned it is not a bug. https://github.com/python-poetry/poetry/issues/9679#issuecomment-2340523397 explains why. However, you cannot create a universal lock file without having access to all dependencies. You can poetry install
with an existing up-to-date lock file without having access to dependencies that are not required on the target platform.
I did not find anything in the docs where this is explained in detail so maybe we should add an FAQ entry or put it somewhere else. If you do not feel comfortable to contribute to the docs, feel free to open a documentation issue. However, I do not think it makes sense to keep this issue open because it is not a bug.
So, to be clear: it is not possible to have a path
specified dependency that is platform dependent in Poetry. Is that correct?
It is. But it doesn't mean it can be absent when locking on another platform
It is correct, or it is possible to have a path
dependency that is platform dependent? If you mean the latter, based upon your comment that "it doesn't mean it can be absent when locking on another platform", then that's a very constrained use case. Basically, it only applies when relative paths are used. Even if Poetry resolves paths in a cross-platform independent way, it is very unlikely for a path dependency on Windows to be in the same location (i.e, have the same path) as on Linux.
Description
Poetry does not respect a dependency which has an environment marker set and seemingly tries to resolve the other components when a marker dictates that the dependency is not valid for the given environment.
For example, on Windows 11, add a new dependency like the following:
Then when running any Poetry command, such as
poetry install
, Poetry fails to run and complains:This is a particular dependency which I don't have any control of on Linux and is installed differently on Windows. Thus, I set the marker to install the dependency via path only when on Linux. But now, Poetry fails to install anything.
Workarounds
None
Poetry Installation Method
pipx
Operating System
Windows 11
Poetry Version
Poetry (version 1.8.3)
Poetry Configuration
Python Sysconfig
Example pyproject.toml
Poetry Runtime Logs