add announcement for upcoming stdlib migration #2126
Conversation
✅ Deploy Preview for conda-forge-previews ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
pre-commit.ci autofix |
for more information, see https://pre-commit.ci
news/2024-03-20-stdlib-migration.md
Outdated
| - if a feedstock uses a `- {{ compiler(...) }}` jinja in the build section, | ||
| add a line with `- {{ stdlib("c") }}` to the build environment. | ||
| - if a feedstock uses `- sysroot_linux-64 2.17 # [linux64]` (or a variation), | ||
| remove this line and add the following to your `conda_build_config.yaml`: | ||
| ``` | ||
| c_stdlib_version: # [linux] | ||
| - 2.17 # [linux] | ||
| ``` | ||
| - if a feedstock sets `MACOSX_DEPLOYMENT_TARGET` in `conda_build_config.yaml`, | ||
| for example to 10.13 for `x86_64`, replace that section with the following | ||
| (note, this does _not_ apply to `MACOSX_SDK_VERSION`!): | ||
| ``` | ||
| c_stdlib_version: # [osx and x86_64] | ||
| - 10.13 # [osx and x86_64] | ||
| ``` | ||
| You should then also remove any line involving `__osx` from `meta.yaml`. |
There was a problem hiding this comment.
Should we put this info in our knowledgebase entries on using compilers? It might already be there, IDK.
There was a problem hiding this comment.
Agreed that this would be a welcome addition to the knowledge base or compilers. We could link to the entry from the announcement so it doesn't get as long. Should help with discoverability!
There was a problem hiding this comment.
Should we put this info in our knowledgebase entries on using compilers?
Yeah, but that would realistically need to build on #1950, which has been waiting for feedback/resolution. Perhaps I need to bring up this topic in the core call.
We could link to the entry from the announcement so it doesn't get as long. Should help with discoverability!
Yeah, that sounds like a good idea.
There was a problem hiding this comment.
That PR doesn't have the new stdlib setup stuff in it for the knowledgebase that I can see.
There was a problem hiding this comment.
Yeah, that PR's about a year old. My point is that if we want to add stdlib handling to our compiler docs, I want to build on the existing clean-up rather than do two conflicting updates.
There was a problem hiding this comment.
We could link to the entry from the announcement so it doesn't get as long. Should help with discoverability!
Yeah, that sounds like a good idea.
I actually reconsidered this and don't necessarily agree anymore. The docs definitely need to be updated, but they should describe the new status quo, not a transition (or at least not for long, as it will become stale quickly).
The announcement (or tracking issue) seems like a reasonable place for me to describe the main mechanics of the transition, especially to the degree that it allows maintainers to do it themselves, without having to wait for the piggyback migrator.
There was a problem hiding this comment.
My main concern was about the discoverability of that information, but the search features should reveal both, so no strong feelings about it. I trust your judgment :)
There was a problem hiding this comment.
So I only added a promise to update the docs for now, for two reasons:
- I want to see this working in the wild before we write docs
- I want update infrastructure.rst/compilers #1950 to land first, but the announcement shouldn't have to wait for that.
Hope that's alright.
|
@conda-forge/core, any opposition to merging this as-is? I'll update the docs as soon as #1950 is settled. |
|
Thanks for the reviews! |
As discussed in #2102