Switch to uv?

[gforcada]

It has been on the headlines for quite a while, a fast(er) replacement for pip, but not only that.

Should we switch to it on our GHA? 🤔

I made a test PR on plone.batching: plone/plone.batching#83

The changes are mostly to be done here in plone.meta and roll them over to the distributions.

❗ one caveat though: as soon as we change the workflows in this repo, i.e .github/workflows/XXX.yml all repositories that depend on them will (probably 🤔 ) break, so it might be a good idea to first move all repositories to point to a stable version, and then merge this, so we can freely break stuff without breaking repositories 😅

My idea:

• make a 1.0 release of plone.meta
• update all distributions with:

jobs:
  qa:
    uses: plone/meta/.github/workflows/qa.yml@1.0.0
  test:
    uses: plone/meta/.github/workflows/test.yml@1.0.0
  coverage:
    uses: plone/meta/.github/workflows/coverage.yml@1.0.0
  dependencies:
    uses: plone/meta/.github/workflows/dependencies.yml@1.0.0
  release_ready:
    uses: plone/meta/.github/workflows/release_ready.yml@1.0.0
  circular:
    uses: plone/meta/.github/workflows/circular.yml@1.0.0

• we can then start making breaking changes in plone.meta 🎉

@davisagli @mauritsvanrees does it sound sane? 🤔

[davisagli]

@gforcada I was thinking about this too. It's easy enough for us to update Plone packages, but there are also collective packages which started using plone/meta (https://github.com/search?q=org%3Acollective+plone%2Fmeta%2F.github&type=code) and I'm worried we won't find everything that needs to be updated to use a specific workflow version. Probably there are private packages too.

Ideas:

1. Set the main branch in stone (pretend it's a tag) and create a new 2.x branch, and make it the default. Then we can add a version to the workflow in the future but we don't have to update existing places it is used.
2. Release 1.0.0, then update the workflows on main to give a hard error with clear instructions on how to update it to use the tag.

[gforcada]

@davisagli thanks for the input! We already have a previous attempt at the shared-workflows folder 😅

Maybe indeed, letting main set in stone and use branches for each new major change is a better idea, so we don't exactly pin all packages to a certain version e.g 1.5.4, but with a 2.x branch we can keep updating the workflows and fine tune them while giving certain stability 👍🏾

[jensens]

+1 for uv and +1 for a 2.0 then

[mauritsvanrees]

Sounds good.