Noarch variant blog post #2332
Noarch variant blog post #2332
Conversation
✅ Deploy Preview for conda-forge-previews ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
pre-commit.ci auto-fix |
Co-authored-by: jaimergp <[email protected]>
Co-authored-by: Filipe <[email protected]>
Not really. I was looking at packages in my dev environment that had compiled extensions. |
|
I'll keep this open for a couple of days for comments and merge. Thanks for the reviews. |
There was a problem hiding this comment.
One small nit/question, rest looks good!
Possible improvements:
- I think it would be helpful to provide some things to look for for contributors to tell whether a given package has a pure python fallback implementation, because not all do...
- We might want to reference the efforts around abi3 & limited ABI, which are kind of adjacent in terms of thrust (while they are compiled, they'd still be usable immediately when a new python implementation/variant comes out).
| In the Python world, some packages are written in C/C++/Cython | ||
| to get the most performance out of a package. However these packages | ||
| have a reference implementation written in Python. The Python |
There was a problem hiding this comment.
Missing "often"?
| In the Python world, some packages are written in C/C++/Cython | |
| to get the most performance out of a package. However these packages | |
| have a reference implementation written in Python. The Python | |
| In the Python world, some packages are written in C/C++/Cython | |
| to get the most performance out of a package. However these packages | |
| often have a reference implementation written in Python. The Python |
I don't want to start announcing those things until they are ready. |
|
@jaimergp any idea on the CI failure? |
|
We don't use Go for anything. Push an empty commit to see if it was a flaky thing on Netlify's side and if not I'll check tomorrow. |
| code against a much simpler python implementation and is also | ||
| useful for platforms like PyPy where the C/C++/Cython implementation | ||
| can be slower than the Python reference implementation due to the | ||
| emulation of the Python C/C++ API by PyPy. For eg: for the Cython |
There was a problem hiding this comment.
Would just spell this out (particularly for non-native English readers)
| emulation of the Python C/C++ API by PyPy. For eg: for the Cython | |
| emulation of the Python C/C++ API by PyPy. For example for the Cython |
| reference implementation is to look at `setup.py` on packages that | ||
| provide such a file to see if `extensions` are built always or | ||
| with a switch. |
There was a problem hiding this comment.
As some projects are moving away from setup.py, these details may be elsewhere
Also suggested a more succinct rewording
| reference implementation is to look at `setup.py` on packages that | |
| provide such a file to see if `extensions` are built always or | |
| with a switch. | |
| reference implementation is to look at the library's source code | |
| to see if `extensions` are optional. |
| no reference implementation. This makes early adopters of new Python | ||
| versions to wait for the conda-forge bot managed by @conda-forge/bot | ||
| team to start the migration and rebuild the packages. For eg: the |
There was a problem hiding this comment.
| no reference implementation. This makes early adopters of new Python | |
| versions to wait for the conda-forge bot managed by @conda-forge/bot | |
| team to start the migration and rebuild the packages. For eg: the | |
| no reference implementation. This means early adopters of new Python | |
| versions need to wait for the conda-forge bot managed by @conda-forge/bot | |
| team to start the migration and rebuild the packages. For example the |
| free-threading Python 3.13 build is still not under way because | ||
| conda-forge has decided to wait until the default (GIL enabled) | ||
| Python 3.13 build has migrated enough and upstream packages have added | ||
| support for free-threading builds. |
There was a problem hiding this comment.
There might be a cleaner way to write this. Tried a first pass below
| free-threading Python 3.13 build is still not under way because | |
| conda-forge has decided to wait until the default (GIL enabled) | |
| Python 3.13 build has migrated enough and upstream packages have added | |
| support for free-threading builds. | |
| free-threading Python 3.13 build is still paused as | |
| conda-forge has decided to focus on the default (GIL enabled) | |
| Python 3.13 build first while upstream packages work on | |
| supporting free-threading. |
| or test time and this requires manual handling to reduce dependencies | ||
| before the migration and add the dependencies later on. |
There was a problem hiding this comment.
| or test time and this requires manual handling to reduce dependencies | |
| before the migration and add the dependencies later on. | |
| or test time and this requires some manual handling. |
| We list some PRs here as a reference for conda-forge maintainers who | ||
| want to help out with this effort. | ||
|
|
||
| - [coverage](https:/conda-forge/coverage-feedstock/pull/123) | ||
| - [cython](https:/conda-forge/cython-feedstock/pull/147) | ||
| - [aiohttp](https:/conda-forge/aiohttp-feedstock/pull/99) |
There was a problem hiding this comment.
It might be nice for readers to include an example from a simple one in the blogpost itself. Perhaps could use a diff format to highlight relevant changes
PR Checklist:
docs/orcommunity/, you have added it to the sidebar in the corresponding_sidebar.jsonfilecc @ocefpaf @h-vetinari