Initial introduction of a opam-release tool

[CohenCyril]

This is a tool to generate a branch of opam-coq-archive (and a pull-request manually) from the opam meta data local to the repository.
Most of the arguments are inferred automatically if one:

• has a unique file named .opam
• is using a github repository
• has their github username configured in their global .gitconfig
• has performed git remote update
• the dev-repo is set in the opam file
• opam is installed

Arguments can be supplied to fix any of the default behavior (or their absence thereof).
One can witness the inferred arguments by providing option -s

NB: this is a generalization of mathcomp packager

@Zimmi48 @palmskog @gares

[Zimmi48]

Great to see more of math-comp specific tools get generalized for the larger community!

[palmskog]

Looks reasonable, but how does it compare to, say, dune-release? I can see the benefit for make-based projects, but wouldn't dune-release still make more sense for a Dune-based project?

[gares]

Is github.user customary? Is it used by other tools?

[CohenCyril]

Looks reasonable, but how does it compare to, say, dune-release? I can see the benefit for make-based projects, but wouldn't dune-release still make more sense for a Dune-based project?

This is a simplistic approach to publishing opam. I believe dune based projects should use dune release instead.

[CohenCyril]

Is github.user customary? Is it used by other tools?

You can provide it with -u. But yes this is a standard thing cf https://docs.github.com/en/github/using-git/setting-your-username-in-git

Mine is set because I frequently use the hub command line tool.

Edit: apparently I got confused about this... Let me sort it out and come back with a better answer

[CohenCyril]

So apparently user.name is the github recommended way but I think this is too much of "github supremacy" (what about users that use other plateforms where they don't share the same username?) and other tools used to use github.user, so think I will first try github.user and then fall back to `user.name.

[gares]

That is used in the git commits, and is standard, but is not necessarily linked to github's user name. I'd propose user.github.login

[CohenCyril]

Yes I'm having trouble to find out which tool I am/was using that used github.user

[CohenCyril]

Ah, I found it, its emacs magit: https://magit.vc/manual/ghub/Setting-the-Username.html

EDIT: I can link this webpage in the usage message

[CohenCyril]

That is used in the git commits, and is standard, but is not necessarily linked to github's user name. I'd propose user.github.login

I see no reason why not reusing the magit convention. I could support this one additionally, but do you think it is necessary?

[CohenCyril]

It's also used in gitnub cf https://github.blog/2008-10-11-local-github-config/

[gares]

The magit one is fine, it will just work for some users.

[CohenCyril]

I added a few options and failsafes thanks to @proux01 remarks.

[CohenCyril]

@proux01 I added correct failures (and non-failures) for when github.user is not set, I added a version test for opam (which will not use --check-upstream if not available) and a new option -r LOCAL_OCA so that you can reuse a local clone to speed up downloads (it does not touch it, you may still have to update it manually, but it performs an update on the local copy anyway, so it shouldn't change the behavior whether it's up to date or not, just the time).

[gares]

I finally remembered where I've seen this before. https://github.com/ocaml-opam/opam-publish
Can you compare the two?

[CohenCyril]

I finally remembered where I've seen this before. https://github.com/ocaml-opam/opam-publish
Can you compare the two?

Thanks for pointing that out, I did not know it. Well it does the job provided you pass enough options. E.g. For coqeal I had to do:

opam-publish --repo "coq/opam-coq-archive" --packages-directory=released/packages https://github.com/coqeal/coqeal/archive/1.0.5.tar.gz -v 1.0.5

to get the job done. I guess I could do a wrapper, but most of my script is about figuring out the ideal parameters... I could replace the last 40 lines by a call to opam-publish, to get better guarantees maybe.

[gares]

That is what I had in mind, you could wrap it.
IIRC it is easy to provide opam command, you can probably have opam coq-publish be the invocation of your wrapper.

[CohenCyril]

That is what I had in mind, you could wrap it.

I could also contribute to it by adding the missing features and a --coq option that sets things correctly...

[Zimmi48]

It's good to hear that opam-publish is usable for Coq projects. I thought I had heard that it wasn't the case because it didn't provide enough options. Note that using opam-publish gives you an experience that's slightly different since it wants you to generate a GitHub token IIRC.

[gares]

If it works like dune release, then not having the token results into a branch being pushed but no PR opened automatically, which would be sort of a feature if the user was informed: you are one click away, but you have a chance to check things are OK.

[gares]

(or at least, this is my observation of a non documented "feature")