Add multiple Python version environments and test during CI

[fjclark]

Description

Add environments with explicit Python versions and test them during CI. This addresses @lilyminium's question on slack. I've only added 3.11 and 3.12 at the moment (though I realise SPEC0 recommends 3.12, 3.13, and 3.14) because I couldn't resolve the deps for newer versions due to e.g. nnpops.

Status

• Ready to go

[lilyminium]

Thanks @fjclark! Is there any way to to do this without needing to update the lock file each time? You can see in #140 that I've expanded the environments to 4: default, pydantic-1-cpu, ambertools, openeye, and it's a bit of a pain to have to specify this for all of them, especially for full spec0 where that would be 12 environments.

On #140 I don't use the lock files for the ubuntu environments so that CI picks up the most modern versions of each package, which I think is also generally better for a CI workflow, as it tests whether things are still working without requiring manual updates -- unfortunately this didn't work so well for the mac environments due to issues resolving cuda. I was hoping for a way these more flexible Ubuntu environments could receive environment information specifying python versions, but it seems like Pixi isn't really set up to handle this?

[fjclark]

Ah, sorry for misunderstanding! I agree it gets pretty verbose though my understanding is that it's in-keeping with the philosophy of pixi to resolve all envs explicitly once and store them in the lockfile for reproducibility.

Is there any way to to do this without needing to update the lock file each time?

Afraid I haven't come across an example.

I don't use the lock files for the ubuntu environments so that CI picks up the most modern versions of each package, which I think is also generally better for a CI workflow, as it tests whether things are still working without requiring manual updates

Maybe explicit environments with https://pixi.prefix.dev/v0.41.4/advanced/updates_github_actions/ to regularly update the lockfiles would be a reasonable compromise? Though this is still a bit more manual work.

[lilyminium]

Thanks Finlay! Yeah, it seems like that's the only way, and Josh made a good case for having to manually enumerate environments being a minor downside compared to the benefits in #140. I think I'd like to get #140 in first -- would you mind enumerating all the environments available there now that it's merged? Happy to take over this PR too if you'd rather hand it off.

[codecov-commenter]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[fjclark]

Replaced by #147