Conda-forge testing package with numpy 2.0.0rc2 although we pin 'numpy <2'

Not sure if this is the best place for this, please let me know if some other channel is suited better.

Our feedstock was sent an automated PR to migrate to numpy 2 build process. The migration guide in the opened PR says to pin numpy <2 in run section if package is not yet numpy 2 compatible.
Even though I already did that before and so it is also in the automatic PR being evaluated by CI, during the testing part of the built package, numpy 2.0.0rc2 is installed in the environment for testing. I even now added a numpy <2 pin for the tests section package specs but still numpy 2.0.0rc2 gets installed to run tests on built packages.

It’s a common gotcha in the version ordering rules.

2.0.0 > 2.0.0rc, so when you pin <2 you are allowing all the prereleases before v2 stable. The solution is to pin <2.0dev0.

1 Like

Makes sense, thanks! Probably would be good if the migration bot had that in his message instead

We added Adjust upper bound wording numpy 2 migration by jaimergp · Pull Request #5968 · conda-forge/conda-forge-pinning-feedstock · GitHub now, thanks!

Hmm – this seems like, shall we say a “bad idea” – not so much that the versioning rules are as they are – after all >=2.0 shouldn’t bring in 2.0.0rc.

However, shouldn’t pre-release versions never be brought in unless asked for explicitly?

Or did I miss something, and this only applies to pre-release testing build?

1 Like

No, it always applies. This is not usually a problem because we don’t publish pre-releases to main, so you don’t see it in your solves unless you opt in with e.g. -c conda-forge/label/matplotlib_rc.

There was a PR for conda to add a --pre flag like pip does, but it stalled. Maybe worth resurrecting.

1 Like