You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After #1416 and the surrounding discussion have settled on adding the invariant "within the workspace" to the Path type contract, installAs and installIn in their current forms are (A) potential ways of breaking that contract and (B) not particularly useful if that contract is enforced. If, on the other hand, they were refactored to return Result Unit Error rather than Result Path Error, they could very cleanly fulfil their intended purpose of copying build artifacts to system locations without exposing holes in the API.
This is a breaking change, though, as they have been used to shuffle files around within the workspace in the past. However, claimFileAsPath: String => String => Result Path Error can serve a similar purpose, and we can introduce a copy: String => Path => Result Path Error which does restrict the destination to fill the gap where we already have the file as a Path (and it would finally have the proper semantics unlike every one of the current functions).
installIn becomes much less relevant because we aren't usually going to have a Path directory to install the file into unless it's an intra-workspace copy, but we are going to want a variant which takes an access mode to apply; user/group ownership might be helpful but is likely not going to be used often enough to include, when the alternative is following the install with a simple enough localRunner job.
The text was updated successfully, but these errors were encountered:
After #1416 and the surrounding discussion have settled on adding the invariant "within the workspace" to the Path type contract,
installAs
andinstallIn
in their current forms are (A) potential ways of breaking that contract and (B) not particularly useful if that contract is enforced. If, on the other hand, they were refactored to returnResult Unit Error
rather thanResult Path Error
, they could very cleanly fulfil their intended purpose of copying build artifacts to system locations without exposing holes in the API.This is a breaking change, though, as they have been used to shuffle files around within the workspace in the past. However,
claimFileAsPath: String => String => Result Path Error
can serve a similar purpose, and we can introduce acopy: String => Path => Result Path Error
which does restrict the destination to fill the gap where we already have the file as a Path (and it would finally have the proper semantics unlike every one of the current functions).installIn
becomes much less relevant because we aren't usually going to have a Path directory to install the file into unless it's an intra-workspace copy, but we are going to want a variant which takes an access mode to apply; user/group ownership might be helpful but is likely not going to be used often enough to include, when the alternative is following the install with a simple enoughlocalRunner
job.The text was updated successfully, but these errors were encountered: