[WIP] Windows - esyi: Use forked OPAM repo on Windows for esyi

[bryphe]

The forked OPAM repository here: https://github.com/fdopen/opam-repository-mingw has windows-specific patches and fixes for popular packages, making this more reliable for windows builds.

[andreypopp]

We should think of a long term strategy regarding using multiple opam repos — with this PR it means that projects which are developed both on windows and nix might get packages from different opam repos during version upgrades:

1. Windows user inits project and lockfile locks packages to versions from windows opam repo.
2. Unix user adds a package to the project and that package comes from regular opam repo.
3. Windows user fails to build it.

Another problem is that windows opam repo isn't updated as fast as regular opam repo (I suppose).

[bryphe]

We should think of a long term strategy regarding using multiple opam repos — with this PR it means that projects which are developed both on windows and nix might get packages from different opam repos during version upgrades:

The ideal world is that we don't need to use a forked repo - it'd be great if the packages just worked cross-platform!

However, unfortunately that's not the case today - a good example is the issue we hit with #295, which is blocking both reason and esy from building. In that case, there is a bug with menhir that causes it to fail on Windows - which is addressed by this patch to the forked repo: fdopen/opam-repository-mingw@54c3e01

Seems like we have a few options:

• OPTION 1: Try and push these fixes directly to the packages, side-stepping the need for using a forked repo. I don't think this is viable in the short term for Windows, but might be the ideal long-term approach.
• OPTION 2: When building on Windows, we substitute the forked repo for the core OPAM repo. As you mentioned, this might be confusing because we'd get packages from different OPAM repos on different platforms, for the same package.
• OPTION 3: We port windows specific fixes / patches to our esy-opam-override. This seems tenable but also means duplicating a bunch of the work done at fdopen/opam-repository-mingw.

The strategies aren't mutually exclusive - it makes sense to pursue OPTION 1 opportunistically while we 'bootstrap' the windows ecosystem. But we will need a solution for the items that are currently blocking Windows build, like #295

@andreypopp , let me know what you think!

[bryphe]

Based on our discussion - it sounds like using the windows opam override repo isn't ideal. It doesn't make sense since we would need to generate different lock files per-platform, and have different versions of packages. Our plan moving forward is to port over patches we need to our esy-opam-override repo.