Skip to content

Conversation

@jaimergp
Copy link
Member

PR Checklist:

  • note any issues closed by this PR with closing keywords
  • if you are adding a new page under docs/ or community/, you have added it to the sidebar in the corresponding _sidebar.json file
  • put any other relevant information below

Closes Quansight-Labs/conda-ecosystem-sta-mgmt#58

@jaimergp jaimergp requested a review from a team as a code owner November 21, 2025 16:03
@netlify
Copy link

netlify bot commented Nov 21, 2025

Deploy Preview for conda-forge-previews ready!

Name Link
🔨 Latest commit 0a7eb7b
🔍 Latest deploy log https://app.netlify.com/projects/conda-forge-previews/deploys/6932bc3b3f3cf70008579e34
😎 Deploy Preview https://deploy-preview-2660--conda-forge-previews.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
Lighthouse
Lighthouse
1 paths audited
Performance: 68
Accessibility: 96
Best Practices: 100
SEO: 89
PWA: -
View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify project configuration.

Comment on lines 14 to 15
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!
Copy link
Contributor

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".

Copy link
Member Author

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.


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.
Copy link
Contributor

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.

Copy link
Member Author

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)


## 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).
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See 01e6598

Copy link
Contributor

@mgorny mgorny left a 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.

Copy link
Contributor

@mgorny mgorny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Copy link
Member

@h-vetinari h-vetinari left a 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).

@jaimergp
Copy link
Member Author

jaimergp commented Dec 2, 2025

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!

Copy link
Member

@h-vetinari h-vetinari left a 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.

Copy link
Member

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_64

With 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?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @mfansler! Check 0a7eb7b and let me know if that suffices!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Diátaxis: How-to guides - Advanced - Enable osx-arm64 and other architectures

4 participants