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

Fix dask-core / distributed pinning to properly exclude nightlies #191

Merged
merged 2 commits into from
Aug 19, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions recipe/meta.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -10,16 +10,16 @@ source:
sha256: a14c1c5143081701d4fe62283e09cc5ad5336dff3a152de64eb77ee3180e9792

build:
number: 1
number: 2
noarch: python

requirements:
host:
- python >=3.8
run:
- python >=3.8
- dask-core ={{ version }},!={{ version }}a*
- distributed ={{ version }},!={{ version }}a*
- dask-core {{ version }}.*,!={{ version }}a.*
- distributed {{ version }}.*,!={{ version }}a.*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am still a little worried about adding .s here not behaving correctly. From the Conda-Builds docs on run:

Package names should follow the package match specifications.

From the match spec docs:

* matches 0 or more characters in the version string. In terms of regular expressions, it is the same as r'.*'.

The fuzzy constraint numpy=1.11 matches 1.11, 1.11.0, 1.11.1, 1.11.2, 1.11.18, and so on.

So the previous syntax should already be doing what we want. The fact it isn't is a little strange and may indicate a bug.

The use of .s shouldn't be needed and may lead to incorrect behavior.

Given all this, am wondering if the , is what is causing us issues

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the comma could be what's causing the issue here - I noticed that from the conflict message I shared in #190 (comment) that a .* seemingly got appended to the end of our constraint automatically.

I'm not sure if this is documented anywhere, but I would assume it gets done to map fuzzy constraints from the conda install style to the conda build style, i.e.

numpy=1.11 -> numpy 1.11.*

but might not be expecting there to be two constraints in one line and so ends up behaving strangely.

I'll try out your suggestions and see if those get the intended behavior - out of interest, is there a way to inspect the dependencies of a locally built conda package? Trying mamba repoquery depends but not sure if it has support for local packages

charlesbluca marked this conversation as resolved.
Show resolved Hide resolved
- cytoolz >=0.8.2
- lz4
- numpy >=1.18
Expand Down