install report (windows): conflict with dkml

[emillon]

Hi,

I have the following experience to report on windows. I installed opam 2.2.0~beta3 from winget, but it's conflicting with a previous forgotten dkml install. Here are my interactions:

• install works well (though I'm initially confused by the diskuv.opam name and the dkml url)
• opam init says it cannot configure cmd, and then exits without doing anything. I suppose cmd is not supported, and retry with powershell. same thing.
• I discover that there's nothing to do in opam init, because there's already an opam root
• I delete opamroot with Remove-Item
• now opam init works, but detects the ocamlc 4.14.0 from dkml 2.0.2 and uses it as a system switch
• I try to run the uninstaller from dkml, but it doesn't work
• I remove dkml from AppData "by hand"
• now I can create a non-system default switch

I'm not sure what to fix / if there's anything to fix, but this might come up again in the future so I figured I'd open this. Thanks

[kit-ty-kate]

I try to run the uninstaller from dkml, but it doesn't work

we do not maintain that installer/uninstaller, could you report this at https://github.com/diskuv/dkml-installer-ocaml/issues instead?

opam init says it cannot configure cmd, and then exits without doing anything. I suppose cmd is not supported, and retry with powershell. same thing.

This seems to be the only thing we can fix on our side. Could you expend on that? What does the message looked like?

[jonahbeckford]

I try to run the uninstaller from dkml, but it doesn't work

we do not maintain that installer/uninstaller, could you report this at https://github.com/diskuv/dkml-installer-ocaml/issues instead?

• I'd just tell the OP ~you~ to wait until 2.2 is released before trying to get DkML and opam 2.2 to co-exist. I do not think it is a good idea to overload the opam 2.2 release with DkML compatibility ... I don't believe that was ever a goal. opam 2.2 should advertise that an upgrade to opam 2.2 should require a complete uninstall of DkML and Visual Studio 2019 before any install attempt of opam 2.2, and redirect opam 2.2 users to the DkML release notes pages. I'm fine with tweaking https://gitlab.com/dkml/distributions/dkml/-/releases#upgrading-from-versions-earlier-than-210 to say how to do a fool-proof uninstall of everything except opam root.
• And I'd also say that the release notes for 2.0.2 say "The uninstaller for DkML 2.0.2 is broken. You'll need to wait for the next release (ie. 2.0.3 or 2.1.0) to get a working uninstall64*.exe.". https://gitlab.com/dkml/distributions/dkml/-/releases#202-2023-07-27.

[emillon]

Yes, I understand that this installer is not handled by opam itself, but maybe it could detect this situation. Otherwise, feel free to close this issue.

This seems to be the only thing we can fix on our side. Could you expend on that? What does the message looked like?

I'll get back at you with that info.

[dra27]

• now opam init works, but detects the ocamlc 4.14.0 from dkml 2.0.2 and uses it as a system switch

Just to confirm or check further - this is intended behaviour, right? opam on Linux also creates a system switch by default if you have a system compiler?

[dra27]

@jonahbeckford - the only possibility for 2.2.0 is that opam init might recognise that there's an existing DKML installation and display a warning, rather than anything further. Although I agree that just documenting this may well be the best approach.

[emillon]

• now opam init works, but detects the ocamlc 4.14.0 from dkml 2.0.2 and uses it as a system switch

Just to confirm or check further - this is intended behaviour, right? opam on Linux also creates a system switch by default if you have a system compiler?

Yes, I think that's reasonable, though the only indication that I was not on the "golden path" of opam init is that it was very quick (and also using 4.14.0, which isn't a version number I'd expect to see in a fresh install otherwise). Well, and the fact that it was ocaml-system.