cmdliner 2.0.0 support
It seems that the latest version of your package on the opam repository will not compile with the upcoming cmdliner 2.0.0 release.
This is either because you are using deprecated identifiers that are removed in 2.0.0 or because you still use argument converters as pairs which has been (sadly only silently) deprecated since 2017.
There are a few instruction here on how to make it compatible. If you run into problem or need more help use this issue, I'm listening.
This concerns the packages opam-client.2.3.0 and opam-installer.2.3.0.
Whether or not we can support cmdliner 2.0.0 will depend on the status of https://github.com/dbuenzli/cmdliner/issues/200 If this is given the go ahead with no escape hatch, we'll probably sadly have no choice but fork the latest stable version of cmdliner 1.x instead.
I don't think so, as mentioned in the instruction I linked to:
Projects can handle all breaking changes performed by 2.0 and still compile with cmdliner.1.3.0
I'm not sure to understand. Do you mean cmdliner will still behave the same with regards to prefixes in 2.0.0?
No it won't. But as far as I know these packages do not install opam the tool which is your worry.
I understand there is still some hesitance towards cmdliner 2.0.0 in opam for backwards compatibility concerns, but is it possible that there will be a intermediary point where the source code of opam's tools can be compiled with cmdliner 2.0.0, even if the .opam files still request 1.3?
For context, the bound on opam-installer currently means that you cannot create a cmdliner 2.0 opam switch that does both native and windows cross-compilation at the same time if you rely on any projects that need .install files.
If there was an at-least-source-compatible release, we could work around this in opam-cross-windows by e.g. adding a new package with the bound altered and having our files depend on that, but at the moment I think we've got no good options
Hi, sorry for this inconvenience. I wasn't aware opam-installer was used in this way in the cross-compilation repositories, that's pretty cool.
I'm currently in vacation but the current plan is to vendor cmdliner 1.3 in opam-core. This should be part of 2.5.0~alpha2 which should be released in about 2 to 3 weeks. In the meantime i've opened https://github.com/ocaml-cross/opam-cross-windows/pull/385 which is a quick fix version of the above plan (although with a bit more duct-tape), i hope this helps.
Ah, that would also work! I don’t think anyone besides me is really clamoring for it at the moment, so I’ll take a look at the duct tape version but we might just wait for the proper release in that case
Thank you!
opam is blocked in Fedora because of lack of cmdliner 2.0 support (https://koji.fedoraproject.org/koji/taskinfo?taskID=138146300)
@rwmjones feel free to use the same temporary hack
While (as I understand it) you've added a workaround for this, could we leave the bug open so we have a way to track when actual 2.0 support is added?
@rwmjones #6755 is the proper fix, not a workaround. opam 2.5 and above doesn't depend on cmdliner anymore.
Since Fedora is unlikely to take the latest 2.5 beta (planned to be released on Monday) but stay on opam 2.4, we've also provided you with the patch on top of 2.4.1: https://github.com/ocaml/opam/pull/6757. You can get the patch here: https://patch-diff.githubusercontent.com/raw/ocaml/opam/pull/6757.diff
I see, thanks. We might actually move to the beta but I'll discuss with the team.