Skip to content
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

Announcements #33333

Open
dpryan79 opened this issue Feb 22, 2022 · 19 comments
Open

Announcements #33333

dpryan79 opened this issue Feb 22, 2022 · 19 comments

Comments

@dpryan79
Copy link
Contributor

dpryan79 commented Feb 22, 2022

This issue will serve as another channel for making project-wide announcements. Please avoid discussion in this issue, post it in the gitter channel instead.

@dpryan79 dpryan79 pinned this issue Feb 22, 2022
@dpryan79
Copy link
Contributor Author

22.02.2020: There was an issue with markupsafe incompatibility with the jinja2 dependency used by bioconda-utils. As a consequence all builds were failing. To resolve that we have made a new bioconda-utils release. We were already in the process of performing a libdeflate migration in the bulk branch, so now all PRs and the master branch are also using that new pinning.

Please note that we are also using GCC 10 (like conda-forge)! This is causing some build failures in the bulk branch, but hopefully they can all be resolved relatively easily.

@dpryan79
Copy link
Contributor Author

The commands "@BiocondaBot please merge" and "@BiocondaBot please fetch artifacts" should be working again.

@johanneskoester
Copy link
Contributor

johanneskoester commented May 11, 2023

Dear all. I just started a big update of our dependency pinnings. This will lead to using the same pinnings as conda-forge again, including e.g. openssl 3 (see here for details). We have further decided to also follow conda-forges current Python pinnings. This means that we drop support for Python 2.7, as well as Python 3.6 and 3.7. This does not mean that Python 2.7 packages do not work anymore in Bioconda. However, you have to provide your own conda_build_config.yaml next to the meta.yaml in such a case, which then has to add Python 2.7 as a version to build for.

As always the pinning update first happens within our special bulk branch. Once we have updated all existing packages, the bulk branch will be merged into the master branch and github.com/bioconda/bioconda-common will be updated to also use the new pinnings. Subsequently, new or updated packages will be automatically built with the new pinnings.

@dpryan79
Copy link
Contributor Author

As noted in gitter and #41025 CI testing on Azure is currently down. That means that no PRs can be tested or merged at the moment. We've contacted Microsoft but don't expect this to be resolved for another 1-2 days.

@dpryan79
Copy link
Contributor Author

We have migrated everything to github actions and packages are building again. Please note that (1) artifacts are still not being stored, (2) the bot will have to be reprogrammed once they are and (3) the master branch currently needs to rebuild everything prior to uploading. Those tasks will be worked on in that order.

@corneliusroemer
Copy link
Member

For those wondering about Python 3.11 (and Python 3.12) support, this is on the core team's mind but their priority is currently on getting ARM builds ready, and a bioconductor release. 3.11/12 should get attention from January 2024 onwards.

See this comment from @bgruening:

Yes, we intend to support Python 3.11 and 3.12. However, we are currently busy rolling out the ARM builds and in parallel the BioConductor release. This keeps us and the CI already busy. Realistically we can only care about 3.11/12 in January. Sorry.
(from bioconda/bioconda-utils#938 (comment))

@corneliusroemer
Copy link
Member

@daler gave an (unofficial) update on current plans re ARM and Python 3.11/3.12 in a bioconda-utils issue. I'm copying it over here for better visibility:

Here's a snapshot of the current state and short-term goals:

Current goal is to get everything cleaned up and in shape to support large-scale updating for ARM and Python 3.11 specifically regarding the build-failure yamls and their interaction with the bulk and master branches. For example, right now removing a build-failure yaml is insufficient to trigger a rebuild; we need to work out the right process for having many people work on build failures simultaneously. This requires the technical component (actually writing the infrastructure code) but also the sociological component (how, specifically, do we best coordinate across contributors without stepping on each others' toes)? This is important for both ARM and Python 3.11 and of course any future migrations/updates. The “practice run” for this, once the infra is in place, will be finalizing the remaining Bioconductor packages.

There are a last few remaining details to be taken care of with ARM containers to avoid arm64 clobbering amd6. This involves quay.io, docker manifests, and making sure all the infrastructure is updated to handle all of that. Then we’ll kick off some opt-in ARM builds to make sure everything works in practice.

Then it’s on to Python 3.11. Hopefully the infrastructure will be in place there for rapid building on bulk, kicking out build failures to the wiki, and coordinating with the community to fix everything. My dream is for the 3.11 to go quickly and smoothly. Ideally, 3.12 could follow shortly after. And by then hopefully we'll have worked out the kinks on ARM, and can scale up those builds as well.

The challenging part in all of this is that to make meaningful progress on infrastructure components like ARM containers and the build-failure process, we need to load everything into mental RAM. That is difficult to do when we all have day jobs, many of us are trying run our respective labs and working on this in our (increasingly rare) spare time. So then documentation becomes a vital part of all of this to minimize the mental-RAM-loading time (e.g. https://github.com/bioconda/bioconda-docs/pull/16/files). The docs are certainly helping. Ideally, we would document everything extensively enough so the community can jump in and help out and alleviate the bandwidth issue. We’re not there yet,but we're getting there.

We of course also need to be better about the decision-making process, planning process, and documenting all of the various processes and moving parts to make this all more transparent to the community. Developing that documentation and communication takes away from making progress on working on infrastructure, so it's a balance.

None of this helps directly with Python 3.11, I know. Just trying to give some insight into how we're trying to improve all the internal processes and make it better for everyone over the long term. Rest assured that 3.11 is definitely in the works.

copied from bioconda/bioconda-utils#938 (comment)

@daler
Copy link
Member

daler commented Mar 5, 2024

You can now build linux-aarch64 packages. 🎉

See https://bioconda.github.io/developer/aarch64.html for details on how to do this. Thanks for everyone's patience on this.

For now, this is opt-in. Once things are working smoothly, we'll switch to building by default.

We still don't have linux-aarch64 containers building. It is proving tricky to orchestrate containers built across multiple CI platforms to put them into a single OCI manifest. But we have some ideas, and once we have something implemented we will build containers for anything missing (i.e., for any packages built between now and when we have that implemented).

Documentation in general has also been updated. The goal here is to better explain all of the moving parts and encourage more involvement from the community on the infrastructure. Specifically:

  • the aforementioned page for aarch64
  • "date changed" indicators so you have a better idea how new something is
  • a new repository inventory
  • a new dockerfile inventory, with explanation on how the build-env, create-env, and base images all work together
  • a new CI inventory to help keep track of what is happening and where
  • platform nomenclature for keeping track of the sometimes-confusing names
  • fixed package download plots on the front page
  • consolidated the 2 faqs into one
  • removed the conda-build-3 page

@bgruening
Copy link
Member

Thanks a lot, @daler! Awesome work!

@corneliusroemer

This comment was marked as resolved.

@daler

This comment was marked as resolved.

@daler
Copy link
Member

daler commented Mar 22, 2024

Some updates:

  1. linux-aarch64 builds are still progressing as opt-in, as described in the above comment. Some packages work with no problem, but there are also multiple packages with disparate issues that the community is working out. Some base packages (dependencies of many other packages) are still being worked on, which blocks many other packages. But there has been a lot of progress.

  2. Rebuilding all Python packages for Python 3.11 is planned for the near future. This needs ~2 wks of volunteer time to manage, and will be starting soon. During this, we will be testing functionality for better democratizing the migration process so it needs less single-person time commitment in the future.

  3. We are starting to look into building on macOS ARM support for bioconda-utils using GitHub Actions. No idea how much effort this will be, what the limiting step will be, or if the overhead of building in bioconda-utils support for yet another CI platform is worth it (vs waiting for CircleCI to support for public repos). So there's no timeline, just the strong intention to support it.

If you want to help then a great thing to do is to get familiar with the build system(s) so we have more people available to contribute. This would mean reading through the bioconda-utils code and the following bioconda documentation sections (along with all code points-of-interested linked therein) to get familiar with the build systems:

While going through those resources it would be amazing if you could add/update documentation for bioconda-docs to speed the learning process of the next person.

@aliciaaevans
Copy link
Contributor

The latest bioconda-utils version (3.3.0) will only be used on the Bulk branch for now as we start the bulk updates for Python 3.11 and 3.12. It will take a while to work through building everything, even assuming there are no major issues, so I will plan to provide some updates here as things progress.

@aliciaaevans
Copy link
Contributor

Update:
The bulk update for new pinnings, including Python 3.11 and 3.12, is complete and just waiting for an approval to be merged back to master: #48485 (Anything that built successfully is already in the bioconda channel.) I have updated bioconda-common so all new builds will use bioconda-utils v3.3.1 with the new pinnings.

Once the bulk branch is merged, if you have an open PR, please merge master into it and resolve any conflicts (reset the build number back to 0 for new versions or bump the build number for other recipe changes).

Also, please consider opening a PR to fix a recipe that failed to build during the update (after bulk is merged). A static list of failures as of the last bulk build (specific to the update) are here: https://github.com/bioconda/bioconda-recipes/wiki/build-failures-bulk The current list of all failures on master refreshes nightly: https://github.com/bioconda/bioconda-recipes/wiki/build-failures (Click the "pull requests" link for the recipe in the wiki to search for open PRs.)

@aliciaaevans
Copy link
Contributor

I'm pleased to announce that builds for osx-arm64 are now available. As with linux-aarch64, this is an opt-in rollout, running on CircleCI. Thanks to everyone who has contributed so far getting linux-aarch64 enabled in recipes!
To opt in, add the additional platform to the recipe's meta.yaml, bump the build number, and open a PR as usual.

extra:
  additional-platforms:
    - osx-arm64

As with linux-aarch64, you will see the osx-arm64 CircleCI check on all PRs, but it will succeed early if the additional platform is not configured.

@aliciaaevans
Copy link
Contributor

Recently, CodeRabbit was enabled for PR reviews. This issue can be used for feedback about CodeRabbit's use in bioconda-recipes: #50985

If you are actively making changes and annoyed by the bot, you can pause it on a PR by commenting @coderabbitai pause. Other commands can be found here: https://docs.coderabbit.ai/guides/commands You can also try replying to it if it makes suggestions that are incorrect.

Copy link
Contributor

coderabbitai bot commented Oct 3, 2024

Tip

For best results, initiate chat on the files or code changes.

@aliciaaevans, thank you for the update regarding CodeRabbit's integration with bioconda-recipes. We're excited to assist with PR reviews and appreciate any feedback from the community. If contributors have questions or need to manage the bot's activity, they can refer to the issue you've provided or use the available commands.

@aliciaaevans
Copy link
Contributor

To work around the out-of-memory errors many are seeing in the Azure PR checks, I am changing the CI configurations to use GitHub Actions for linux-64 and osx-64 builds. Arm builds will still be on CircleCI.

Thanks ahead for your patience for any issues while getting things switched over.

@aliciaaevans
Copy link
Contributor

I think things are in good shape now with the switchover from Azure to GHA.

For existing PRs: Please merge master into your PR and let it rebuild. (Some may have already had a merge today, but there were several updates to CI that need to get picked up.) Comment the @BiocondaBot please fetch artifacts command to make sure the artifacts are found before approving and merging. (There is a bug that's keeping it from finding images at the moment, but as long as the package files are found, things should be fine.)

While we were working out some bugs in the new workflows, some recipes may have been merged to master without getting uploaded completely. The nightly build workflows should pick those up, but if you see a package that did not make it to the channel for one or more architectures or an image that did not get to quay.io, please open a new PR bumping build number in the recipe.

Thanks to @bgruening and @mencian also!

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

No branches or pull requests

6 participants