Determine Github repo from the dev-repo opam field #414
Description
The current situation
At the moment, mostly because of delegates, dune-release tries to parse the home, dev-repo and doc fields on the to-be-released opam package. This overly complex logic makes it hard for a lot of people to use the tool.
It's hard to release dune using dune-release for instance because its home points to the read the docs, which makes dune-release think it's not hosted on github. The only way to work around that is to set an obscure env variable before running dune-release and this is really annoying.
The proper behaviour
This feature depends heavily on having removed support for delegates, i.e. on #188.
Once we drop delegates, we can simplify all of this. At this point, some operations will only support github hosted repositories instead of using delegates. That means we'll have to determine if the repo is hosted on github, proceed if it is and fail if it's not.
The proper way to determine that is not by parsing the home or doc field which can point anywhere depending on how and where users want to host their packages websites even though the repo is still on github. The dev-repo field holds exactly the information we need and therefore that's the only field we should parse to determine if it's hosted on github and if so, where exactly.
This information will then be used just as it is now, to create a release and upload the release tarball on the github repo.
What about gh-pages documentation?
We used to rely on the doc field to determine whether we should publish the documentation to gh-pages.
This part is more subject to debate.
One thing we currently do is to skip the documentation publication is there is no doc field and this might be something we want to preserve.
Using the value of the doc field to determine whether to publish the documentation is a bit of a different matter. It might be the case that some packages want to host the manual on readthedocs but the API documentation on gh-pages. That's the case of ocaml-ppx/ppxlib for instance.
My intuition is that the documentation situation needs some thinking as the current situation is not great. Is only publishing the documentation when you release what people really want? What about multi-opam repos? Do we handle those correctly?
Before we tackle this broader issue, I think we shouldn't use the doc field to determine whether to publish documentation or not.
I think it would be better to have a good default (publish it as we do now if it's github hosted), allow both to abort or skip this step via the prompt before actually doing it and add the proper CLI options. flags or arguments to the main command so the default behaviour can be overwritten. It's currently only possible to do that from the publish subcommand by passing an explicit list of targets.