tarides
custom opam repositories are not well-handled
Hello hello!
First, dune-release is really a fantastic piece of software!
That being said, I ran into some trouble today that I managed to solve but this might help someone else. (And I suggest that these should be seen as issues with the current code.)
When using a custom opam repository, you can't use dune-release directly, you have to follow each step in order until the last dune-release opam submit, which you have to write as dune-release opam submit --opam-repo=your_org/opam-repository.
The second issue is that you need write access to that repo, so if you don't have write access to the custom repo you need to create your own fork (let's say mimoo/opam-repository), and apply the PR there. Then you can manually merge it, and create a manual PR from mimoo/opam-repository to your_org/opam-repository.
The third issue is that what you initialized dune-release with will most probably conflict with what you're trying to do. So I would delete the file ~/.config/dune/release.yml every time before a release (otherwise the custom repo you set there might conflict with the --opam-repo option.
The release.yml file should look like this once you re-initialize it with a specific opam repo:
user: mimoo
remote: [email protected]:mimoo/opam-repository
local: path/to/my/clone/of/that/repo
Thanks for reporting this!
We should indeed add the --opam-repo to the default command, that's an omission on our part.
That being said, the rest is not exactly true, I for instance do release to a custom opam repository quite often when testing dune-release and do not experience any of the problem you mention. You should not delete your release.yml config file, just properly set it up the first time. The remote field should point to your own fork (or one you have write access to) of ocaml/opam-repository or the opam repository you want to release to. The local field should point to your local clone of that repo or fork, again dune-release should pull and push to the right places (i.e. pull from --opam-repo and push to your config's remote).
If your configuration is set up this way, it should all work fine. One thing that might happen is that the opam repository you want to release to is not based on ocaml/opam-repository, in which case you might not be able to share the same fork for releases to the custom and the regular opam-repo.
If that's the case I'd advise you set the --local-repo and --remote-repo CLI options accordingly to override your configuration rather than delete the config file everytime.
The key point here probably is the lack of documentation for dune-release and we're well aware of that. It might also be the case that these kind of workflows are not perfectly well supported or rather that you'll encounter bugs when trying more custom release workflows. We've been working to improve the experience for all users of dune-release lately so I expect things are getting better and better but there's still work to do on that front so don't hesitate to report any rough edges or bugs.
We've also considered adding some kind of per-repo configuration so that when you want to release different repos differently you don't have to pass a whole bunch of CLI options for that to work. This is not there yet and we unfortunately have higher priority things to fix and improve so in the meantime I'd suggest you have a small script that invokes dune-release with the right set of option in your repo for that purpose, keeping your most common remote and local in your global config file.
It's also worth noting that we recently discovered bugs and inconsistencies in the configuration and the way it is handled by the tool so expect improvements on that front as well!
just properly set it up the first time
if I understand correctly this only work if you only/most often release to the same custom opam repository. But I imagine that the ideal scenario for most people is instead to release to the official opam repository, unless a custom repo is passed no?
We've also considered adding some kind of per-repo configuration so that when you want to release different repos differently you don't have to pass a whole bunch of CLI options for that to work. This is not there yet and we unfortunately have higher priority things to fix and improve so in the meantime I'd suggest you have a small script that invokes dune-release with the right set of option in your repo for that purpose, keeping your most common remote and local in your global config file.
Interesting, another issue I had was that I don't have write permission on the custom opam repo I'm trying to publish to. So I had to use dune-release to publish on my own fork, merge it manually there, and then create a manual PR from my fork to the repo I wanted to publish to (if that makes sense).
It's also worth noting that we recently discovered bugs and inconsistencies in the configuration and the way it is handled by the tool so expect improvements on that front as well!
Ah yeah, I also had issues with the synopsis/descr/description field. I had to write three lines and use "descr" because both "description" and "synopsis" wouldn't work.
I also had to set a project name in the dune-project folder and I was wondering what this was for (and what I should set it to if I have multiple opam packages in there).
Could you clarify this part:
I had was that I don't have write permission on the custom opam repo I'm trying to publish to. So I had to use dune-release to publish on my own fork, merge it manually there, and then create a manual PR from my fork to the repo I wanted to publish to (if that makes sense).
The fact that you don't have write access to the repo you want to release to actually is the nominal use case, most people using dune-release don't have write access to ocaml/opam-repository but they still can release there. What dune-release does is that it pushes a branch to your fork (the remote field in the config) and open a PR to the repo, custom or not. I suspect you either ran into a bug or misinterpreted the erros you got. Would you mind trying that again, with the master branch of dune-release and paste the output here so I can better understand what exactly is going on?
Ah I see. So if I understand correctly this is the command I should run to submit a PR on org/opam with my fork on mimoo/opam cloned locally in path/to/local/mimoo/opam:
$ dune-release opam submit --opam-repo=org/opam --local-repo path/to/local/mimoo/opam and --remote-repo mimoo/opam
Is that right?
Yep exactly!
The issue I was mentioning about the config above is that the user field is redundant with remote. We'll soon delete it to use only the latter but in the meantime, to avoid weird bugs I'd set it to the remote fork owner, so in your case mimoo. That basically mean adding --user mimoo to the above command line invocation.
I also had to set a project name in the dune-project folder and I was wondering what this was for (and what I should set it to if I have multiple opam packages in there).
The project name is required by dune subst which dune-release calls when building the distribution tarball. This command replaces watermarks such as %%VERSION%% with the appropriate value in your sources. It also has a %%PROJECT_NAME%% hence the need for the project name. In general I think it's good practice to have one set. If your project provides multiple opam packages, I'd use the main one if there's any such package, or simply the name of the repository otherwise but that's entirely up to you.
We're also working on multi-opam repositories handling in dune-release and we might use the project name to try and figure out what is the main package if there's one but this is still WIP atm as we're still figuring things out on this front!