Firedrake release

[connorjward]

Summary

This PR is a place to collect the final changes that are necessary for a release to be made.

In terms of process, I think we should, once all dependent PRs are sorted:

1. Merge this PR
2. Check that it works
3. Create a release branch
4. Build the versioned Docker containers and publish on PyPI
5. On main, amend pyproject.toml to point to git repos and add dev install information

TODOs

Installation

• Set the Firedrake version to 2025.4.0 in pyproject.toml
  - [ ] Write firedrake-dev-install, a script that lets users install a usable Firedrake main and associated packages (there will not be an associated firedrake-update and like firedrake-configure it will be extremely dumb)

Workflows

• Update CI such that we can test both main and release branches (the install procedure will be slightly different due to needing --no-build-isolation for the former)
• Add workflow for building and publishing sdist (copy from UFL)
• Change Docker workflow to build and publish containers after a release is made (probably best to be able to trigger manually if required) instead of after merging main.

NOTE: I have removed the zenodo canary workflow. It used firedrake-install.

Zenodo

• Rewrite firedrake-zenodo as appropriate
• Remove note in install.rst about it

IMPORTANT: Testing firedrake-zenodo is quite the pain and so I have not tested the core dev half of the script. My thinking is that we can fix this when someone actually asks us to make a release and we need to run it for real. I have checked that the initial generation of firedrake.json works.

Documentation

• Update install documentation
  • Describe how to get a developer install working (this should point to the main website)
• Figure out how to build two websites for the different branches
• Finalise policies and processes for making releases (draft here)

See also the release GitHub project (I am choosing not to use this here because I don't want to create a million issues that all get closed in a single PR).

[francesco-ballarin]

Write firedrake-dev-install, a script that lets users install a usable Firedrake main and associated packages

Are you really sure you want to go down this road? You've put months of efforts into removing firedrake-install, only to add it back with a slightly different name?

Wouldn't it be possible to reuse firedrake-configure to work for both release and main versions? Maybe with a flag, or by checking whether the script lives in a git repository?

[connorjward]

Write firedrake-dev-install, a script that lets users install a usable Firedrake main and associated packages

Are you really sure you want to go down this road? You've put months of efforts into removing firedrake-install, only to add it back with a slightly different name?

Wouldn't it be possible to reuse firedrake-configure to work for both release and main versions? Maybe with a flag, or by checking whether the script lives in a git repository?

The issue is the process for installing master Firedrake is very different to for a release since we have to pass --no-build-isolation and install all the dependencies manually since the pyproject.toml doesn't have the right information any more.

I guess I'm trying to make it easier for people to git clone Firedrake, FIAT, pyadjoint and UFL so they don't need to do them all manually.

I was thinking that this script would be written in bash and very simple, just containing a list of commands with little to no control flow. It would be handy in CI too.

[dham]

Could we not just have a different pyproject.toml on main compared with release?

[connorjward]

Could we not just have a different pyproject.toml on main compared with release?

The trouble is we have to build with --no-build-isolation so that we install Firedrake using the right petsc4py, which disables any dependency resolution.

[francesco-ballarin]

Could we not just have a different pyproject.toml on main compared with release?

I'd say so. For instance, I would guess that on the release branch there is a dependency on "fenics-ufl" (i.e., from PyPI), and on the main branch there is one on "fenics-ufl @ git://github@main", and part of the process of creating a new release would be to remind yourselves to drop the references to the github repository.

The trouble is we have to build with --no-build-isolation so that we install Firedrake using the right petsc4py, which disables any dependency resolution

What does "disables" mean? My understanding is that it disables automatically fetching build-system.requires, but it still automatically installs project.dependencies.

For instance, at
https://github.com/fem-on-colab/fem-on-colab/blob/fad58dc3d3ea89ae174ecfb11658e21560b65d28/firedrake/build.sh#L86
I am installing with --no-build-isolation, yet I am not installing manually UFL, pyadjoint etc. I only need to manually install libsupermesh and rtree, because they are in build-system.requires.

[connorjward]

What does "disables" mean? My understanding is that it disables automatically fetching build-system.requires, but it still automatically installs project.dependencies.

Oh interesting! I was led to believe that this was not the case.

In that case I think we are safe to maintain different pyproject.tomls on main and release and use firedrake-configure etc. Please forget everything I said about firedrake-dev-install!

[connorjward]

I am forcing this through now as the release process HAS BEGUN!