Allow to bump more than one formula at once for synced formulas

[Porkepix]

Provide a detailed description of the proposed feature

Some formulas are synced in versions and needs to be updated all at once (see list here: https://github.com/Homebrew/homebrew-core/blob/master/synced_versions_formulae.json), but the various bump commands doesn't allow to provide more than one formula to it (brew bump-formula-prat least; I discovered brew bumpjust now, but it seems providing more than one formula to it would just produce the same as calling the command many times, each time with one of those formulas.

What is the motivation for the feature?

Make it easier and without needs for manual steps to updated synced formulas.

How will the feature be relevant to at least 90% of Homebrew users?

It would be relevant to people updating those formulas.

What alternatives to the feature have been considered?

The alternative is the current way of doing those, mainly manually (people used to it might have better ways of doing it than what I found, but I don't think there's anything currently allowing to update those as easily and quickly as unsynced formulas).

EDIT: We could even imagine than when user run the command on a single formula, brew automatically consider adding all the other synced formulas.

[MikeMcQuaid]

This is a great idea, thanks @Porkepix!

[MikeMcQuaid]

brew bump may be able to do this already?

[MikeMcQuaid]

brew bump may be able to do this already?

Sorry, missed that in the original part. I think implementing this in brew bump may be the solution that we want here and save brew bump-formula-pr for the single formula case?

[Porkepix]

brew bump may be able to do this already?

No, from what I understand, brew bump foo bar baz will pretty much provide the same results as running brew bump foo ; brew bump bar ; brew bump baz, therefore breaking the audit check on synced formulas.

Don't know if it's nice to limiting it to one case or not, I just discovered brew bump yesterday by reading here. It have its advantages, but also offer less options than the other commands for now.

[carlocab]

I agree this needs to be fixed, but here's how to use bump-formula-pr on formulae with synced versions:

git checkout -b foo-1.2.3
for f in foo bar baz qux
do
  brew bump-formula-pr --write-only --commit --no-audit --version=1.2.3 "$f"
done

You're now ready to create a PR from branch foo-1.2.3.

[Porkepix]

I agree this needs to be fixed, but here's how to use bump-formula-pr on formulae with synced versions:

git checkout -b foo-1.2.3
for f in foo bar baz qux
do
  brew bump-formula-pr --write-only --commit --no-audit --version=1.2.3 "$f"
done

You're now ready to create a PR from branch foo-1.2.3.

Yup, that sure works, I just never bothered creating a dedicated ssh key on the mac from my work and only have the token, for which it was annoying to look at how to use it manually, leading to this strange setup where I was doing edits on my PRs on my personal (Linux) computer /o\

For the purpose of this issue, at some point I was looking for a way to "pause" the bump-formula-pr command between its modifications and the timing it was opening the PR to do any needed additional modifications, but this is much more work here and maybe not wished (and it's a bit what the write-only do, but it lacks a way to resume and push what's currently done to GitHub without having to do things manually.

[carlocab]

but it lacks a way to resume and push what's currently done to GitHub without having to do things manually.

You can script the creation of the PR with

gh pr create

Without any arguments, this starts a dialogue that will ask you to fill in the contents of the PR (title, post body, etc). But you can skip that too with the appropriate flags.

[gromgit]

I'm currently working on a PR that checks the bumped formula against synced_versions_formulae.json, and automatically bumps and adds all the other synced formulae to the same PR. I assume that's the desired behavior?

[Porkepix]

but it lacks a way to resume and push what's currently done to GitHub without having to do things manually.

You can script the creation of the PR with

gh pr create

Without any arguments, this starts a dialogue that will ask you to fill in the contents of the PR (title, post body, etc). But you can skip that too with the appropriate flags.

Yes but then it won't be opened like regular formula bumps, right?

I'm currently working on a PR that checks the bumped formula against synced_versions_formulae.json, and automatically bumps and adds all the other synced formulae to the same PR. I assume that's the desired behavior?

At first what I had in mind was rather the ability for users to specify more than one when calling brew bump or brew bump-formula-pr, but then I thought of the behavior you described in my edit, yes. Also, what do you have in mind regarding already edited files and/or (but I think it's a bit out of topic here) showing those synced formulas in brew info? I regularly use the bump to also check against dependencies if those can be updated and so on.

[gromgit]

what do you have in mind regarding already edited files

For those, and all others where the bump changes fail to apply, I'm thinking an error.

showing those synced formulas in brew info

I don't think that's a good idea. "Other formulae which are synced with this one" is not an intrinsic property of a formula, so throwing that info up to end-users just leads to the sort of confusion that begins with "so do I need to install all these other formulae too?"

[Porkepix]

what do you have in mind regarding already edited files

For those, and all others where the bump changes fail to apply, I'm thinking an error.

Because current state is that if I edit the formula before running the bump, for example to change a dependency version, it comes with the bump (which I found quite useful, in the absence of "pause" mechanism during the bump.

showing those synced formulas in brew info

I don't think that's a good idea. "Other formulae which are synced with this one" is not an intrinsic property of a formula, so throwing that info up to end-users just leads to the sort of confusion that begins with "so do I need to install all these other formulae too?"

Mmmmh, you're right. My point was for people who bump to don't get the surprise of bumping 5 formulas when you thought you was only bumping one, because then they couldn't have checked the 4 others before, to check their dependencies and so on.

[gromgit]

Because current state is that if I edit the formula before running the bump, for example to change a dependency version, it comes with the bump (which I found quite useful, in the absence of "pause" mechanism during the bump.

I'm not (planning to) change the way the bump is applied on each formula individually. The operative phrase is:

where the bump changes fail to apply

i.e. it leads to a conflict on commit. This could lead to a bump failure if a synced formula (say, git-gui) is locally "dirty", even if the formula you were bumping (git) was "clean".

My point was for people who bump to don't get the surprise of bumping 5 formulas when you thought you was only bumping one, because then they couldn't have checked the 4 others before, to check their dependencies and so on.

I don't really see a way around that, since a fair number of version-synced formulae actually depend on a "primary" in the group (e.g. git-svn depends on "git"), so:

• if you bump git alone, git-svn gets tested against the new git during CI, but still remains at the old version
• if your bump git-svn alone, then it gets built against old git

That said, there is at least one problem case: qt has several version-synced database formulae, but all of them (except qt-postgresql) conflict with each other, so unless I misunderstand the build process, all of them have to be separately PR'd after the main qt bump is properly committed. I don't know how (if at all) such a multi-stage CI process can be supported.

[carlocab]

You can script the creation of the PR with

gh pr create

Without any arguments, this starts a dialogue that will ask you to fill in the contents of the PR (title, post body, etc). But you can skip that too with the appropriate flags.

Yes but then it won't be opened like regular formula bumps, right?

What do you mean by "opened like regular formula bumps"? But, regardless of what this does mean, I think you should be able to pass flags to gh (or otherwise interact with the dialogue in the absence of flags) so that it does do this.

[Porkepix]

That said, there is at least one problem case: qt has several version-synced database formulae, but all of them (except qt-postgresql) conflict with each other, so unless I misunderstand the build process, all of them have to be separately PR'd after the main qt bump is properly committed. I don't know how (if at all) such a multi-stage CI process can be supported.

But this problem already exists today, right? How is handled right now?

What do you mean by "opened like regular formula bumps"? But, regardless of what this does mean, I think you should be able to pass flags to gh (or otherwise interact with the dialogue in the absence of flags) so that it does do this.

I meant with the command filing every fields for you and no need to worry about what to put in there. The basic idea was, as a resume to have the bump formula do the end of the bump job. For example considering the needed changes were done, whether they were manual or from a previous bump with --write-only to do everything that came after the replacements in the formula: branch creation, commit if there are still things to commit, push, PR opening and so on.

I'm not sure I'm clear in my explanation, but see it as bump splitted in half: --write-only tackle the first half, it would be nice to be able to do the other half that way.

[gromgit]

That said, there is at least one problem case: qt has several version-synced database formulae, but all of them (except qt-postgresql) conflict with each other, so unless I misunderstand the build process, all of them have to be separately PR'd after the main qt bump is properly committed. I don't know how (if at all) such a multi-stage CI process can be supported.

But this problem already exists today, right? How is handled right now?

Heh, forgot to check previous PRs. Turns out the last QT bump included all the synced formulae in a single PR, so I guess it isn't an issue.

[MikeMcQuaid]

I'm currently working on a PR that checks the bumped formula against synced_versions_formulae.json, and automatically bumps and adds all the other synced formulae to the same PR. I assume that's the desired behavior?

@gromgit This would be great if it could turn into a brew bump-formula-pr or brew bump feature! Note that each changed formula should be done in a separate commit.

[MikeMcQuaid]

Passing on this. We'll review a PR but not going to leave it open indefinitely, sorry!