-
-
Notifications
You must be signed in to change notification settings - Fork 307
How to: additional architectures #2660
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
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for conda-forge-previews ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
docs/how-to/advanced/enable-archs.md
Outdated
| 4. Once a PR is submitted, you can help the feedstock maintainers make the build pass. If you have insight into the particular package, **please** chime in, but most of all **be patient and polite**. | ||
| 5. Once the new builds are available from `anaconda.org`, please help the maintainers by testing the packages, and reporting back with any problems… but also successes! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that the list says "before submitting a build request", these steps don't seem to fit. I'd either split it into two lists, or perhaps change the heading to indicate the complete process, and add a step "submit the pull request to conda-forge-pinning-feedstock as outlined in the subsequent subsections".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I splitted the last two items in two paragraphs.
docs/how-to/advanced/enable-archs.md
Outdated
|
|
||
| 1. Make sure the package is not yet built for that architecture. Consult the package page in anaconda.org: `https://anaconda.org/conda-forge/<package-name>`. | ||
| 2. Check if your package is already in the process of being migrated in the [corresponding migration status page](https://conda-forge.org/status/). | ||
| 3. Check the feedstock in question to see if there is already an issue or pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs expanding to answer what to do if there is one. In particular, I think an issue doesn't really change anything per se, but a pull request implies you don't do the steps below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a little sentence (this was carried over from the previous docs)
docs/how-to/advanced/enable-archs.md
Outdated
|
|
||
| ## Enable linux-aarch64 and linux-ppc64le | ||
|
|
||
| The process is the same as `osx-arm64`. The file to edit is `recipe/migrations/arch_rebuild.txt`, and the status page is [`aarch64andppc64leaddition`](https://conda-forge.org/status/migration/?name=aarch64andppc64leaddition). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the steps will always be the same (right?), perhaps it would make sense to move them into the top section, and just list the files, URLs and specific notes in subsections. Maybe even combine everything into a single list, with bullet points for different migrators, and subsections with additional notes. Not sure though, it might actually be more readable this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally, yes, it has been like that. Let me give it a try.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See 01e6598
mgorny
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM, modulo these (I think) typos, and possibly the suggestion.
Co-authored-by: Michał Górny <[email protected]>
Co-authored-by: Michał Górny <[email protected]>
mgorny
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
h-vetinari
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm completely fine to highly recommend going through the migrators first, but IMO we should demystify the conda-forge.yml configuration for this a bit, which people often seem to get wrong, especially the split between build_platform: and provider: (e.g. some piggyback migrators switch to cross-compilation, and suddenly your build fails; you need to be able to interpret conda-forge.yml to understand what's happening).
I'd describe how to do it manually on the "how-to" page, but I could see the argument to move the "this is how conda-forge.yml works" to another quadrant of diataxis (and if so, I guess we can leave this for another PR).
Co-authored-by: h-vetinari <[email protected]>
|
I think both types of information (how-to, reference) would be useful, but I'll tackle them in separate PRs. Can you approve this one if you agree, @h-vetinari? Thanks! |
h-vetinari
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with this for now, though when we add the reference part, the how-to part should IMO be expanded to contain manual instructions (after xref'ing the reference part).
|
|
||
| - Remove the corresponding line from `conda-forge.yml` and rerender. | ||
| - Add a `skip:` directive to your recipe by matching the non-desired platform, and rerender. | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe worth adding a complementary note to the one in osx-arm64 about emulation being the current default here, with a link to Emulated Builds section.
Also, somewhere it should be said that cross-compilation is far more efficient (6-7x faster, IME) and that the build_platform can be set to enable this when considering the Arch migration PR. E.g.,
build_platform:
linux_aarch64: linux_64
linux_ppc64le: linux_64With more details in the Cross-Compilation section.
(On a side note, I find it odd the Cross-Compilation section doesn't have an explicit example of the above build_platform config. So maybe it should go there?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.

PR Checklist:
docs/orcommunity/, you have added it to the sidebar in the corresponding_sidebar.jsonfileCloses Quansight-Labs/conda-ecosystem-sta-mgmt#58