Make sure we use esy version in package build hashes about esy-issues

[jordwalke]

More details: Here's a problem this would fix:

• You build packages, and they're in the cache.
• You upgrade esy itself which assumes packages are built in a particular form/structure.
• The upgraded version finds a hash match and tries to use a cached package build, but it was from a previous version of esy that built in a different form/structure - causing weird failures.

[yunxing]

Looks like we should just completely discard the old cache when install esy?

[jordwalke]

@yunxing Packages can form dependencies on specific versions of esy, and that results in multiple concurrent versions of esy on the system building artifacts. If you upgrade to a new esy, I believe that implies you should version bump, and also update versions you specify as dependencies so that they also use a compatible esy version. esy would be a peerDependency I believe. (Unfortunately, we saw some issues with it not resolving those correctly). As a fallback we should probably always use the version of esy that your top level package specified.

(I'm thinking that the global esy command should by default search for the esy command in your top level project and then hand off the command to that project's specific version of esy, thoughts?).

[yunxing]

@jordwalke I don't know, the extra level of burrito confuses me to reason about this (you need toplevel "esy" to find nested "esy" in order to build a dependency that requires a different version of "esy").

Do you think we should prompt people to install esy globally other than making it as a dependency? (think about the case with yarn, where people have to install it globally).

[jordwalke]

@yunxing The specific format in package.json definitely makes it so that packages need to specify the version of esy they depend on. The only remaining question is how to enforce it.

1. It seems we definitely want a global esy command (correct?)
2. It seems we want packages to have to specify the version of the esy protocol they are using (so that we know how to interpret their config).

Given that, suppose they have two project who are configured for two different versions of esy (esy 1.0 and esy 2.0). Which one do they install globally? How do they build the other project that uses the other version of esy?

Since they have to specify which version of esy they are configured for, what if they did so by simply adding that version as a dependency. That's no more than any other way to configure.

"esy": "1.0.0"

Since it was in their dependencies, then by having the global esy command delegate to the specific version automatically, we now gained the ability for two projects to be built, that depend on two different versions of esy, yet we always had one way to kick off the build - through the global esy command.

[jordwalke]

Is this one done? I thought I saw this implemented.

[jordwalke]

My latest diffs are sufficient - I include the esy version number in cache directory name.