[BUG] lists in pyproject.toml dependencies not handled #463
Comments
|
@dlqqq, is this one you could have a look at? |
|
I'm receiving the same error sequence: |
|
Digging a little further, I think the error arises from how the [tool.poetry.dependencies]
python = "^3.7.1"
jupyter-dash = { version = ">=0.4.2", optional = true }
plotly = "^5.5.0"
dash = "^2.11.0"
pandas = ">=1"
trace-updater = ">=0.0.8"
numpy = [
{ version = ">=1.14", python = "<3.11" },
{ version = ">=1.24", python = ">=3.11" }
]
orjson = "^3.8.0" # Faster json serialization
# Optional dependencies
Flask-Cors = { version = "^3.0.10", optional = true }
# Lock kaleido dependency until https://github.com/plotly/Kaleido/issues/156 is resolved
kaleido = {version = "0.2.1", optional = true}
tsdownsample = "0.1.2" |
|
In learning what Poetry's definitions are, I found this reference that is specific to this bug. |
|
I dont think its possible can handle it the same way via conda, but it seems like grayskull should make some assumption and move on instead of failing. It looks like we need some enhancement here . I started to think through a fix, something like this: but that would only just use the last constraint specified. I think a proper solution would be to make an assumption like "always use the later python version" (and tell the user about it). And then go back and adjust the minimum python version for the recipe. I dont know anything about this codebase, but it seems like there might be some functions in here that could help with version comparisons? For example, I have So I need to compare the two python versions in the dep spec and find the later one, then ensure that the overall python version is compatible or adjusted. Is there a tool in greyskull that can help with those comparisons? |
|
I don't agree that conda can't handle this. It should be possible to do: scikit-image >=0.18.1 # py<311
scikit-image >=0.20.0 # py>=311This obviously doesn't allow you to be |
|
I'm not sure I understand what you mean @xylar . I meant that conda can't handle that same level of detail in a single environment file (or meta.yml spec?). For example if I have an environment.yml file like this: This will solve to |
|
I've discovered that conda can handle a set of requirements, see this example I have working in conda-forge/willow-feedstock/recipe/meta.yaml:
heif = [
"pillow-heif>=0.10.0,<1.0.0; python_version < '3.12'",
"pillow-heif>=0.13.0,<1.0.0; python_version >= '3.12'",
]
- pillow-heif >=0.10.0,<1.0.0<py312|>=0.13.0,<1.0.0>=py312I adapted the list based on the documentation here: Conda Package Match Specs |
|
@kcpevey, yeah, I get that this can be a bit confusing. What Instead, you would have something like: ...
requirements:
host:
- python >=3.8
- pip
run:
- python >=3.8
- scikit-image >=0.18.1 # py<311
- scikit-image >=0.20.0 # py>=311The recipe will be build with various python versions (currently, 3.8 to 3.12) and the I think this shouldn't be too hard to fix in grayskull but I haven't had time to look into it myself. |
|
@darynwhite, I don't think we want something as complex as: That isn't how this kind of case is handled in I don't think conda-smithy is going to be able to handle the syntax you suggested correctly. |
|
Thanks for the explanation! I didn't know about that! I'm working on a solution. I have both deps added to the requirements list but then when I get here, that one liner grabs only the FIRST dep in the list. If I fix that, then I hit this reduction of package names to a set, thereby preventing duplicates. I'll keep pressing on, but I'm wondering exactly how many things I'll break down the line since there seems to be a strong assumption that there will only be ONE spec per package? |
|
@xylar I was successful in building the latest willow-feedstock update with that complex string, albeit a complicated package spec. Here's the latest PR Quoting from the conda-build docs Requirements section
And the Package match specifications say:
That said...I am unable to find a reference for breaking the package spec into two lines, so I don't know what the behavior could be if that is done. I only have the above mentioned Package match specifications documentation to go off of. |
|
@darynwhite, the multi-line approach uses processing selectors, see: Your approach might work fine with conda-build. My concerns are:
The latter is my bigger concern since conda-forge uses |
|
@xylar Thanks for the terminology! I hadn't stumbled my way into that FAQ yet. If I'm understanding this correctly, then these are equivalent: And...I say they are equivalent because I've seen the single-line approach pass the linter and build properly now. The multi-line approach should pass the linter and build properly, based on the documentation I have read and you just shared. So...Based on the original issue here, I agree that the multi-line approach is the best. Thus I believe this: would translate to: Thanks for the conversation and resources! |
|
Hey @xylar, why is it that grayskull has no complaints with a multi constraint dependency specification when they're not from a pyproject.toml using a poetry backend. So something like this makes grayskull raise an error: but this does not: |
Describe the bug
Dependencies like the following in a
pyproject.tomlraise agrayskull.strategy.py_toml.InvalidPoetryDependencyerror:To Reproduce
Steps to reproduce the behavior:
Expected behavior
In this case, there should be a selector:
Environment:
The text was updated successfully, but these errors were encountered: