remove version from ocaml buildId

[EduardoRFS]

This is an alternative to the change made at #1201

Problem

Using big versions lead to a huge reduction in the available path size for ocamlrun who leads to fails during install in a couple of environments

Solution

Instead of making the version configurable, removing the version from the BuildId path solves the same problem of using custom ocaml versions but also solves the problem of big path size to ocamlrun

Problems

I think this approach is sound as this is how the source version path also works, except that we're adding an exception for it when is the ocaml package

Review

To avoid noise I recommend to review each commit at time

[ManasJayanth]

Removing package name only from the compiler package introduces inconsistency. Inconsistencies can make it hard to reason about.

The current solution around using compiler variants isn't ideal, but seems more aligned with things work internally.

I am, generally speaking, reluctant to make introduce inconsistencies to esy internals - because it's easy to forget such exception rules while debugging at hard problem in future.

[EduardoRFS]

@ManasJayanth we can also remove the version from every kind of package, that would make it more consistent globally. The only advantage of having the version on the name is actually to make it easier to find a package. But then we're making a QOL <> consistency trade-off, which may be not desirable.

My opinion is that this will not be a problem as the source of truth for buildId should always be BuildId.make, so you shouldn't never think on how the BuildId is created just that your path is "prefix/BuildId". But the current solution is not okay, as it will fail on a lot of environments and is a big regression from previous versions

[ManasJayanth]

Current solution is low impact. Removing versions from all packages is a high impact change and open to a lot of possible breakages.

[ManasJayanth]

Is there an instance where the current solution fails?

[EduardoRFS]

@ManasJayanth yes, everytime there is not enough space for the path, like

https://dev.azure.com/esy-dev/esy/_build/results?buildId=3419&view=logs&j=463613bb-21d7-574a-8714-ce0c3318e3e5&t=5dc38f41-fb04-53e8-22e7-ac3eb5fe5949

The solution of changing only ocaml version is also low impact, I would easily argue is even lower impact as it's going to be really simple to detect it as it's a core package and most users will not even notice, but the current one everytime you try to install esy you will notice.

Also the current solution your install scripts need to change, which is also an impact for users

[ManasJayanth]

Which install scripts?

[EduardoRFS]

@ManasJayanth #1212 this one, and this default's are also going to fail as 4.12.0 will not match, nor is 4.10.0 like esy, and 4.8.1000. This solution will work with all of them out of the box

[ManasJayanth]

It doesn't have to match. I think there is a misunderstanding.

[EduardoRFS]

@ManasJayanth how exactly it will work if the size is different? It will reduce the maximum size? If so, I misunderstood on how it works.

I don't think is a great UX if you cannot setup a CI because esy will fail and telling people to install on /usr/local is also not a great UX. It's hard to see the current solution as lower impact, as you can clearly see it failing in a couple of places.

While overall this solution is an upgrade from the current release, and the current solution is a downgrade, as this will make the path size consistent across the same user, doesn't matter which ocaml version you're using.

If your concern is changing the internals, we could have a policy if this breaks we rollback to 0.6.7 and find a better solution?

Also I'm seeing on the wild, the problem of the current approach:

[ManasJayanth]

I'm not even sure removing version gives us enough bytes and make considerable improvements. Benfits outweigh the costs

The CI failures mostly seen are because of @esy-nightly/ prefix in the package name.

IMO, when it comes to worrying about conserving bytes in the path length we should worry more about PPX users - they tend to install binaries in much deeper paths. Few bytes from versions wont help there.

Not saying we'd never get rid of versions from paths, but I dont think it's the solution for this problem.