Note that unless I did not read this well, this will prevent people from linking cmdliner and opam libraries.

I honestly have no idea why you decided to make your life so complicated. There are reasonable and simple workarounds that allow you to use cmdliner 2.0.0 directly.

There are reasonable and simple workarounds that allow you to use cmdliner 2.0.0 directly.

I'm just going to mention them because I'm not sure you got them.

1. You can invoke you evaluation function with an env function that returns Some "true" on "CMDLINER_LEGACY_PREFIXES" and behave as Sys.getenv_opt otherwise (or whatever you inject if you use this). This will make your CLI behave exactly as it is now except for one case: Arg.enum value specification.
2. If you think that the exception of 1. is too widespread you can do a Unix.putenv with the corresponding variable set.

2. If you think that the exception of 1. is too widespread you can do a Unix.putenv with the corresponding variable set.

I understand the reluctance to putenv so there is the obvious:

3. Provide your own Arg.enum with the old behaviour which is not black magic.

Note that 1. + 3. gives you exactly what you asked for in this comment.

Is it possible to discuss the opportunity of not doing this? Or at least have a public discussion on why you are doing this?

I would really like to have non utterly broken completion scripts for opam. I refrained from filing issues because I thought that cmdliner 2 would help you fix that. But if you prefer I can flood you with them.

In my opinion the course of action here is creating technical debt for the project (assuming you want to continue using cmdliner), promotes software bloat and is not in favour of opam end users who would likely prefer great completion than prefix specification for a tool they don't operate day to day or only on a very restricted subset.

Note that unless I did not read this well, this will prevent people from linking cmdliner and opam libraries.

dune wraps libraries by default, so modules like Cmdliner_arg are in fact named OpamCmdliner__Cmdliner_arg but accessible as Cmdliner_arg locally, allowing us to avoid renaming every call to the modules. See (wrapped ...) in the dune documentation

I honestly have no idea why you decided to make your life so complicated. There are reasonable and simple workarounds that allow you to use cmdliner 2.0.0 directly.

This is really not complicated, this took me 30mins to make and is quite straightforward. We don't need the new features of 2.0.0, and quite the opposite, upgrading to 1.3.0 minus the deprecation to make it compatible with 2.0.0 is quite a bit more work in itself as this PR shows.

dbuenzli/cmdliner#200 announced the removal of the CMDLINER_LEGACY_PREFIXES workaround in 3.0.0 so we're simply thinking ahead. On a more personal note, i personally think this change is quite user-hostile and this lost my trust to any future change that you might make in cmdliner. I personally think cmdliner 2.0.0 should've been a separate new cmdliner2 library or something like that.

Note that 1. + 3. gives you exactly what you asked for in this comment.

I don't think it does. The comment was asking for a tangible OCaml expression to ensure that if the feature suddenly disappears, the build would fail. Instead, with the environment variable, the build would continue to succeed but things would now break at runtime.

Note that vendoring this doesn't mean we can't go back to using upstream cmdliner in the future, as long as we're not adding our own patch on top of it, it will be as easy to remove the vendor as it was to create it. Maybe we will decide to stop supporting prefixes and have a proper alias system for shorter names in the future for opam 3.x but we would at least like our command line interface to remain stable for the remaining of opam 2.x.

But if you prefer I can flood you with them.

Please do, it's great to know in any case

Besides, as mentioned in the issue #6425 (comment), Fedora packaging is blocked because of the constraint on cmdliner.1.3. Vendoring it now, for the release is a quick way to resolve this issue. As mentioned Kate, we can choose in the future to do in another way.

dbuenzli/cmdliner#200 announced the removal of the CMDLINER_LEGACY_PREFIXES workaround in 3.0.0 so we're simply thinking ahead.

Well that change will not happen before years at which point I would have expected and/or made sure that you would have migrated to the new experience.

On a more personal note, i personally think this change is quite user-hostile and this lost my trust to any future change that you might make in cmdliner. I personally think cmdliner 2.0.0 should've been a separate new cmdliner2 library or something like that.

It's difficult to satisfy everyone but there are very reasonable points that can be made against the feature and from an hci point of view it's much better to have a consistent experience across your cli tools. But I understand programmers rarely understand these hci issues.

I'm sorry to have lost your trust (also please note that you were the only one who expressed disagreement with the change). But I can say that with this move you lost mine. To me this looks like favouring your preference and experience of the tool over providing a great experience to end-users.

But if you prefer I can flood you with them.

Please do, it's great to know in any case

Well I will say that given what is happening here, I'm not really in the mood of helping improve opam. I will rather treat opam as something I have to cope with.