Add alpha releases of Parcels to prefix.dev

[VeckoTheGecko]

This PR introduces alpha conda releases of Parcels.

How to do a release

• Create and merge a PR incrementing the version number in .github/ci/recipe.yaml (e..g, 4.0.0alpha0 to 4.0.0alpha1 )
• Trigger the workflow manually in the "Actions" tab in Github
• Done!

How to install an alpha version

Check the updated docs

---

This tooling looks similar to the Conda Feedstock tooling. Prefix.dev (creators of pixi) is doing a lot of work in this space. I don't think we should move away from Conda Feedstocks for normal releases (this tooling here is quite bleeding edge, and lacks adoption) - but this workflow here is very convenient for our case here.

Additional reading

Pixi with conda forge

The more and more I look at pixi, the more and more I like it. Is anyone using it as their primary tool for building and distributing packages to pypi and conda? I see https://pixi.sh/latest/build/python/#why-is-this-useful and https://pixi.sh/latest/reference/cli/pixi/upload/ , but I don't know how this relates with conda-forges feedstock approach etc. Does using pixi supercede the need for feedstocks? Is this functionality mature enough to depend on at the moment (I see a warning re. stability on the Python building page)
cc @lucascolley - thought you might have thoughts on this

• VeckoTheGecko via Discord

We don’t have a clean integration with publishing to conda-forge yet. We need to implement something like prefix-dev/pixi#4429 which would make it easy to put pixi-build into “conda-forge mode”, then build a nice UX around that. It is feasible that something like that could revolutionise the feedstock model, but I don’t think that will happen super soon.

If all you want is to share your packages easily, the best way is to use pixi-build and pixi upload to a channel hosted on prefix.dev. We would still recommend publishing packages to conda-forge for greater accessibility and compatibility guarantees with other conda-forge packages.

For example, we upload bleeding edge releases of the pixi-build backends to https://prefix.dev/channels/pixi-build-backends, and stable releases to conda-forge.

Pixi-build is still in preview, so we may still make plenty of backwards-incompatible changes at this point. In reality we haven’t been making many such changes though. Whether you want to depend on it is a question of how much bandwidth you have to make a fix if we break some syntax.

We don’t have any functionality for publishing to PyPI, but it is on our minds.

• lucascolley via Discord

[VeckoTheGecko]

@erikvansebille if we want to run this workflow, we have to change v4-dev to our default branch (since that's the branch github looks at for workflows).

I think this matches our dev workflow at the moment anyway where v4-dev is actually the default branch we're working off of.

This also has the perk of all our issues being closed when the PRs are merged. Thoughts?

[VeckoTheGecko]

Doc screenshot:

[erikvansebille]

@erikvansebille if we want to run this workflow, we have to change v4-dev to our default branch (since that's the branch github looks at for workflows).

I think this matches our dev workflow at the moment anyway where v4-dev is actually the default branch we're working off of.

This also has the perk of all our issues being closed when the PRs are merged. Thoughts?

Yes agree to make v4-dev the default branch! That will also make creating PRs easier. So please go ahead and make that change

[erikvansebille]

Also mention that users can continue using their v3 version by doing conda activate parcels (or whatever their ‘normal’ environment is called)?

[VeckoTheGecko]

Done! Also restructured the page a bit so it flows better

[VeckoTheGecko]

[VeckoTheGecko]

Yes agree to make v4-dev the default branch! That will also make creating PRs easier. So please go ahead and make that change

Done! fyi @fluidnumerics-joe