feat: support for yarn projects; improvement: rewrote bump script in python

[fuchsi-huber]

I needed the support for yarn projects to be able to use the bump action for the AP so I used the chance (and the ever more complex bash script in the action as a motivation) to rewrite the bump action in python (with claudes help).

The version numbers for uv projects still follows PEP440, so it's still "v1.2.3.dev1" for those, while yarn projects already get semantic versions "1.2.3-dev.1". Maybe we want to standardise both of them to semver? Also re: our discussions on the API versioning @lewisjared

Also fyi @mikapfl , re: your wish to rewrite this in python ;)

[lewisjared]

Can we use npm instead of yarn as a package manager? the ndc webapps are the only project that uses yarn. Gil liked yarn, but I've only had issues. I use npm for single project repos and pnpm for monorepos. pnpm is super fast.

I would assume that action doesn't pull in the package manager version which might cause conflicts

[fuchsi-huber]

I have added pnpm and npm as possible backends so the AP can transition easily (or keep using yarn)

[lewisjared]

Is this deliberately a project type over a language?

I guess the project type does allow for the distinction between uv and pixi projects which use conda (not sure if that makes a difference here).

These are technically package managers, but a shape-of-the-project label gives us flexibility to support, for example, a "full-stack" that might have slightly different patterns.

[lewisjared]

Nice. Re PEP440 vs semvar - having a single scheme would save effort especially with projects that deal with both (which is our deployment processes now...).

PEP440 and semver look closer than they are when you are in stable release territory. I'm not sure of the impact or what does/doesn't work if we used semver.

The v tag prefix is something to standardise.

[lewisjared]

We should at least do some exploration about the impact before consolidating, but it would reduce some complexity. I would also put exploring using python dynamic versioning instead of the extra post-release bump on the table too. That might conflict with adopting semver as it uses the +{local_version} suffix.

@mikapfl might have some insights. I don't have a solid steer either way I just want to be able to accurately describe stable releases vs unreleased code. the Bookshelf pulls the version identifier, so there are co-benefits to getting this right and consistent.

The difference burned some time for me yesterday

[lewisjared]

https://peps.python.org/pep-0440/#semantic-versioning

The “Major.Minor.Patch” (described in this PEP as “major.minor.micro”) aspects of semantic versioning (clauses 1-8 in the 2.0.0 specification) are fully compatible with the version scheme defined in this PEP, and abiding by these aspects is encouraged.

Semantic versions containing a hyphen (pre-releases - clause 10) or a plus sign (builds - clause 11) are not compatible with this PEP and are not permitted in the public version field.

One possible mechanism to translate such semantic versioning based source labels to compatible public versions is to use the .devN suffix to specify the appropriate version order.

If our tags follow semver we need to translate to PEP440 for the version in pyproject.toml.

So, at a glance, the dimensions are "package" version vs "tag" version. flux needs semver tags to easily use that information to determine what to release. node=semver, python=semver for the package version. git tag=semver?

Does this reduce to bumping via the package manager to handle package version differences, then translating to semver for the tag?

Renovate picks up github releases by default so any differences between the tag and the release version shouldn't matter there.

[fuchsi-huber]

Let's talk about the versioning schemes with @mikapfl once we are both back from our vacations. I will merge this PR as it is for now as the versioning changes are independent of this node support and reimplementation in python.

Issue to continue the discussion about the versioning scheme: #28