Explicitly versioned numpy was introduced in 9dde1d442546588d610e63ba1f198cb314637b3a. This commit forces an explicit version of numpy, both on build and run.
This was done to deal with a problem where conda would build our packages against a newer version of numpy, and then try to run them against an older version if some other package requested so (e.g. it'd build an lsst package against 1.10, but when an LSST package depended on matplotlib, which itself was built against numpy 1.9, it'd try to run our LSST code with numpy 1.9 (which would fail)).
The original solution has a nasty side-effect that it will try to downgrade numpy when our packages are installed (as they explicitly require a version -- 1.9 in our case). That's too restrictive -- we don't actually care about the runtime version, just about the build version. The two should be split, and the build version should remain explicit (==), while the runtime version should use >=.
mjuric
commented
8 years ago
Explicitly versioned numpy was introduced in 9dde1d442546588d610e63ba1f198cb314637b3a. This commit forces an explicit version of numpy, both on build and run.
This was done to deal with a problem where
condawould build our packages against a newer version of numpy, and then try to run them against an older version if some other package requested so (e.g. it'd build anlsstpackage against1.10, but when an LSST package depended onmatplotlib, which itself was built againstnumpy 1.9, it'd try to run our LSST code withnumpy 1.9(which would fail)).The original solution has a nasty side-effect that it will try to downgrade numpy when our packages are installed (as they explicitly require a version -- 1.9 in our case). That's too restrictive -- we don't actually care about the runtime version, just about the build version. The two should be split, and the build version should remain explicit (
==), while the runtime version should use>=.