-
Notifications
You must be signed in to change notification settings - Fork 53
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
implement stdlib Jinja function #239
Comments
This is now considered blocked on, |
conda/conda-build#5053 was closed a while ago, and we're soon getting to a point where conda-forge feedstocks will contain JFYI :) |
Hey @h-vetinari I do still think that the design of the stdlib function was partially because it's hard to change If you had the opportunity to design this feature free from any implementation constraints, would you still do it this way? |
I won't pretend that I'll manage to give an unbiased answer, but I actually like the conceptual separation between compiler and stdlib. It's an aspect I didn't grasp for a long time, perhaps in no small part due learning about the subject matter mostly through conda(-forge), where the stdlib-aspect is hidden away behind infrastructure-magic. In an ideal world, I'd like to be able to treat the standard library as any other host-dependence -- which we unfortunately cannot do, at least for the C stdlib, because conda isn't able to ship that --, but assuming we could successfully fake that, then the environment layering question would be an even stronger argument IMO to also reflect that in the recipe. It would also make it clearer where recipes do not need a stdlib at all (freestanding, or whatever). I get that this arrives relatively late to the game w.r.t. conda, but I kinda think it's worth the migration pain? Not sure why I would otherwise subject myself to this, haha. If I understand your argument correctly, then you're fully onboard with the need for the relevant knobs, but would like to just encapsulate in the compiler-intrinsic (or virtual package, or however we may call it)? The APIs I've seen for that just don't appeal to me all that much (especially since the stdlib metapackage name changes from platform to platform, forcing yet more selectors), aside from not having a transition story (due to conda limitations around selectors etc.). I guess that could still be an option for rattler or the new recipe format though? Overall, I'm not that invested in how the implementation looks exactly, though in case of doubt, I prefer the less magic one. But I also think that - at least for conda-forge in 2024 - we don't have the luxury of postponing this until a hypothetical clean room design including transition story arrives (again, rattler may have more freedom there). AFAICT, this topic was neglected basically since inception of conda-forge and is now starting to bite hard. We really need to fix it ASAP, as in, definitely this year, and some of that work will take months even in the best case scenario. |
Ah, and cross-referencing your last reply from conda/conda-build#5053, you basically said as much yourself:
|
Done in #892 |
The next release of conda-build is going to contain a new function to allow expressing constraints on the c standard library version (and implementation).
We plan to use this extensively in conda-forge, because it is the key to handle packages that require newer glibc or Macos versions than our global baseline (in fact, we cannot properly move our baseline on Macos unless we have this).
Given that rattler-build is shaping up to be the next-generation build-tool for conda packages, we'll likely need the same kind of functionality in this tool eventually. I had briefly talked about this with @wolfv, and the implementation shouldn't be hard. It definitely wasn't a big deal on the conda-build side (most of that PR is docs and tests).
Xref also mamba-org/boa#379
PS. My understanding is that even with conda/ceps#54, there's still jinja functions under the hood, it would just need to have an extra dollar-sign compared to conda-build/boa, i.e.
${{ stdlib("c") }}
The text was updated successfully, but these errors were encountered: