Comments (10)
Wouldn't it be better to deal with it for 2.0? That's less than 6 months away, and at that point there is a hard necessity to deal with C API/ABI stuff.
from conda-forge-pinning-feedstock.
Yeah, that's part of what I wanted to discuss here, not just the backwards compat by default, but also 2.0.
It also doesn't need an immediate decision, there's no urgency AFAICT.
from conda-forge-pinning-feedstock.
I think this will be useful with the 2.0 release, we could pin to 2
and set the environment variables like we do for the C compilers at build time.
from conda-forge-pinning-feedstock.
Reading this, I see the drawback, that we will have an activation script with numpy
and thus some (unexpected) hurdles for maintainers with numpy as a build dependency (if they want a newer numpy
version). What would be the benefit of providing numpy=1.25
as the default? I don't see it.
from conda-forge-pinning-feedstock.
It's perhaps possible to do this without an activation script, that was just the first thing that came to mind...
What would be the benefit of providing
numpy=1.25
as the default?
I don't have a strong argument (or preference) here. But whenever we get to numpy>=1.25 as a default, we'd IMO have to adapt the run-export. It would also be a bit weird to jump from (a future) >=1.24
back to >=1.19
(based on the API default of 1.25), but I guess that could be a one-time transition. It also wouldn't match NEP 29 anymore...
from conda-forge-pinning-feedstock.
I would argue to not move away from the current setup. Even if we set NPY_TARGET_VERSION
using an environment variable, there are 2 issues.
- It might not get picked up by the build system.
- If a project itself sets
NPY_TARGET_VERSION
, the metadata will not be correct.
However if we build with NumPy 1.25 and have >=1.25, we are guaranteed that the metadata is correct even though it could have been looser.
(This is exactly what we do with macos SDK and deployment target by setting them to the same version by default. For eg: if SDK = 11 and target = 10.9, the symbols introdued in 10.15 are visible, but they need to treated as weak symbols in 10.9 which require the developer to handle it correctly in their C/C++ code)
from conda-forge-pinning-feedstock.
However if we build with NumPy 1.25 and have >=1.25, we are guaranteed that the metadata is correct even though it could have been looser.
Also, a looser pin in that case is not necessary better. Most users will want an updated numpy anyway and having that in place will make it easier (faster) for the solver to provide a solution with it.
Sure, there may be a small portion of users who may need older numpy and won't be able to install it but I believe the advantages outweigh the disadvantages.
from conda-forge-pinning-feedstock.
If a project itself sets
NPY_TARGET_VERSION
, the metadata will not be correct.
Isn't that a general problem that we'll have to look out for in any case?
I'm not sure if that is something we could easily determine from a compiled artefact (numpy does embed the C-API level AFAIK), but it seems it would be good to check after building what numpy target version got used
That way we could verify that things didn't get lost or overridden by the project or the build system.
from conda-forge-pinning-feedstock.
Isn't that a general problem that we'll have to look out for in any case?
No. See my comment highlighted below
However if we build with NumPy 1.25 and have >=1.25, we are guaranteed that the metadata is correct even though it could have been looser.
from conda-forge-pinning-feedstock.
I spoke with @rgommers recently, and he mentioned one thing about this that wasn't clear to me before:
Packages compiled with numpy 2.0 will continue to be compatible with the 1.x ABI.
In other words, if this works out as planned, we could support numpy 2.0 right away without having to do a full CI-bifurcation of all numpy-dependent packages. It would mean using 2.0 as a baseline earlier than we'd do it through NEP29, but given the now built-in backwards compatibility, we could set the pinning to 2.0, and manually set the numpy run-export to do something like numpy >=1.19
(which apparently won't be changed until numpy drops python 3.9 support).
No. See my comment highlighted below
I wasn't talking about the tightness/looseness of the constraints, but about projects setting NPY_TARGET_VERSION
in their build scripts somewhere, which has the potential to conflict (in terms of expectations, not constraints) with whatever we do.
from conda-forge-pinning-feedstock.
Related Issues (20)
- Possibility of Intel compiler toolchains? HOT 1
- Dropping CUDA 11.2 HOT 15
- CUDA 12 version in cbc.yaml - plans? HOT 4
- Migration libprotobuf4251 not being performed for abi_migration_branches ? HOT 6
- adding libparallelproj to conda-forge-pinning-feedstock HOT 10
- Decide how to handle newly-split `google_cloud_*` packages HOT 2
- add pre-commit CI to make sure yaml is valid HOT 8
- @conda-forge-admin rerender HOT 1
- @conda-forge-admin rerender HOT 1
- CUDA 12 builds install sysroot_linux-64 2.28 in the build prefix HOT 4
- 3 simultaneous poppler migrations HOT 3
- Add rdkit to global pinning HOT 3
- migrations on arrow-cpp-feedstock run into timeout while rerendering HOT 21
- numpy2.0 migration PRs have numpy1 .26 for python 3.12 HOT 2
- Close Python 3.12 migration HOT 4
- Migration not running for qt6_main HOT 5
- set upload on branch due to pre-commit
- Unblock zlib 1.3 HOT 13
- Add azure-* CPP packages to global pinning HOT 9
- Document new multi-pkg migration functionality HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from conda-forge-pinning-feedstock.