-
Notifications
You must be signed in to change notification settings - Fork 75
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
Stdlib migration issues #2328
Comments
Another example of an output gaining a stdlib-dependence spuriously is in conda-forge/brial-feedstock#34. Tying into the discussion from #2327, @isuruf says it's wrong. I tend to agree (though I'd say "redundant"). IIUC @isuruf's proposal from #2327 correctly, we should only ever add a I can implement this easily, but the downside will IMO be that previously "working" recipes (who didn't have to care about missing the compiler run-exports, because they were essentially always there in a non-trivial environment anyway) will silently produce incorrect metadata. On the other hands, the systems that would be affected are all very old and hardly in use anymore. In any case, I just wanted to record this discussion in a more visible place than spread across various random PRs. |
The migrator didn't notice, because it didn't get taught about |
Copying my comment from #2327 (comment) over:
I agree. |
I think handling the cases incorrectly does much more harm than trying to fix (purportedly) broken recipes. E.g., the |
(N.B.: Didn't see #2330 before; at least from the PR's title, this sounds good.) |
Small improvement for better detection of |
Given that we've been migrating for over a month now, I'm going to close this issue. If you find other things to change in the migrator going forward, please leave a comment here or better: open a new issue and tag me. |
For ease of searching: list of bot PRs (checked first ~100 until pyranha-feedstock)
{{ stdlib("c") }}
. (fix in More stdlib fixes #2329)A larger point of discussion came up in #2327 - in general we only want to add stdlib where there's a compiler already in use. However, there could be cases lurking where feedstocks are "working" right now, but not actually propagating compiler run-exports correctly.
One particular such candidate is having a global build stage and then individual outputs that don't build anything anymore, but just pick pieces out of what the global stage produced. In such a case, if run-exports are not forwarded from the global stage to the outputs, then we would create packages with incorrect constraints, unless we defensively add
{{ stdlib("c") }}
to those outputs as well (which is what #2135 did).The text was updated successfully, but these errors were encountered: