-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Python restricted dependency not working #6895
Comments
Please create a repo that reproduces this as there's enough complexity that a search-and-replace of (likely partially tested) reproducer pyproject.tomls is fraught. That being said, I immediately notice you have |
@neersighted Does this mean that the use of extra groups is not compatible with the use of markers? At this point I wonder if there is a hierarchy of use among groups, extras, and markers in the dependencies, but more importantly whether there are exclusion constraints ("this is not allowed with that"). |
I @neersighted, thanks for the quick answer. That If it is good for you I'm going to leave the PS: in lib_c the |
They're not incompatible; but without seeing a complete real (sanitized real, as opposed to synthetic recreation, as many users do not fully test their minimal reproductions) pyproject.toml(s), it's hard to know if it's not some use of extras not included in the reproduction that breaks things. We have that now, so I'm confident that was merely a red herring. |
probably duplicates #5506 |
I @neersighted, sorry but I cannot fully understand what do you mean with complete real example. I linked a mock repo that can be easily cloned and where the error can be reproduced. Has anybody tried this? Did you have the same unexpected output as mine? If so, I think this should be labelled as a bug. |
We have a real clonable repro; I have not had time to investigate, but thank you for providing it.
This is labeled as a bug, and as requiring triage/someone to reproduce and confirm the details. |
Hi, adding my question here as it looks like a duplicate or something really close. Using Poetry 1.2.2 too.
With above config shouldn't the pass lock file creation be successful as When RF 3.1.2 is changed to 4 (and resolve passes). the |
Hi, is there any update on this? Is there any plan to attack this issue in the nearby future? This unexpected behavior is becoming quite blocking for our organization. |
What feels like another very similar reproduction; Package [tool.poetry]
name = "test_resolve"
version = "0.1.0"
description = ""
authors = ["Some Person <some@example.com>"]
[tool.poetry.dependencies]
python = "^3.10"
napari = [
{version = "^0.4.18rc2", python = "^3.11"},
{version = "^0.4.17", python = "<3.11"},
]
[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api" however, a |
the constraint |
Ah! That works! But shouldn't that be filtered out by the fact that I didn't allow prereleases? |
There is definitely some weirdness going on. It looks like selecting the prerelease explicitly for one of the restricted dependencies implicitly allows resolution of prereleases for all of the others, e.g. napari = [
{version = "^0.4.17", python = "^3.11"},
{version = "^0.4.17", python = "<3.11"},
] doesn't match Perhaps this implicit allow-prerelease was intended - I couldn't find it mentioned in the documentation. Even attempting to force no-prereleases failed (resolved the rc2 on 3.10)
and FWIW the only combination I found to get what I wanted was: napari = [
{version = "^0.4.18rc2", python = "^3.11"},
{version = "<0.4.18a0", python = "<3.11"},
] |
Poetry version: 1.2.2
Python version: 3.9.13
OS version and name: macOS Catalina, Version 0.15.7
I am on the latest stable Poetry version, installed using a recommended method.
I have searched the issues of this repo and believe that this is not a duplicate.
I have consulted the FAQ and blog for any relevant entries or release notes.
If an exception occurs when executing a command, I executed it again in debug mode (
-vvv
option) and have included the output below.Issue
Hi, I'm currently working on a multirepo context and I have a pyproject.toml file that has some other repos between its dependencies. I tried to recreate the situation with three empty repos
lib_a
,lib_b
,lib_c
wherelib_a
depends on the other two.To reproduce the error just clone this repo: https://github.com/carlotardivo/poetry-issue-6895 and execute a
poetry lock -vvv
from lib_a root directory.These are the three pyproject.toml files:
lib_a:
lib_b
lib_c:
Expected result
Basically what I'd expect, according to these docs (python restrcted dependencies) is to be able to create a lock file that allows for the creation of an environment with
lib_b
(withscipy
1.5.*) when python ~3.7.13lib_b
(withscipy
1.8.0) andlib_c
installed only when python >=3.9,<3.10Actual result
The lock file generation breaks with the following error, that seems related to the fact that scipy 1.5 is looked also for python >=3.9,<3.10 (while only ^1.7.0 should in this python range):
I'm I missing something?
Thank you very much.
The text was updated successfully, but these errors were encountered: