Open CohenCyril opened 3 years ago
Great to see more of math-comp specific tools get generalized for the larger community!
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?
Is github.user customary? Is it used by other tools?
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.
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
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.
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
Yes I'm having trouble to find out which tool I am/was using that used github.user
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
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?
It's also used in gitnub
cf https://github.blog/2008-10-11-local-github-config/
The magit one is fine, it will just work for some users.
I added a few options and failsafes thanks to @proux01 remarks.
@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).
I finally remembered where I've seen this before. https://github.com/ocaml-opam/opam-publish Can you compare the two?
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.
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.
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...
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.
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.
(or at least, this is my observation of a non documented "feature")
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:
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