Re-work how esy prefix is used to handle EXDEV
errors.
#21
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the newly introduced (still in beta)
node_modules
linker, the CI (as well as users) might run intoEXDEV
issues when esy hardlinks NPM dependencies from cache to a project path which is on a different drive. On Github Actions Windows runner, for instance, theHOMEPATH
is usually onC:/
and working directory onD:/
.To work around this, the action is better of placing the esy stores (cache) in the same drive that it has access too. With some trial-and-error, I learn, all paths under
D:/
is not necessarily writable. So, this PR computes esy prefix by simply traversing one level up in the current working directory path (where we have write accesss).This however breaks user's assumptions - they'd expect this action to work just like esy does on local machines (i.e. place esy store at
C:/
or$HOME/.esy
. This means, if they simply run esy commands (for instance, if they wish to export esy dependencies as a relocatable cache withesy export-dependencies
), it would not work because the prefix path on the CI is different from default on.To work around this, this action must expose the computed path with GITHUB_ENV or something which users can access as they write CI scripts.
There's a separate UX related issue wrt esy itself when it comes to handling the
EXDEV
problem. It's being tracked here - since this problem is not evident in all cases - only if the project opts into thenode_modules
linker for NPM projects. Perhaps this action could use esy to figure if this custom prefix solution is needed in the first place, in a future PR.