Add a library for looking up runfiles.

[judah]

Relevant Bazel issue: bazelbuild/bazel#4460.

I followed the approach documented here:
https://docs.google.com/document/d/e/2PACX-1vSDIrFnFvEYhKsCMdGdD40wZRBX3m3aZ5HhVj4CtHPmiXKDCxioTUbYsDydjKtFDAzER5eg7OjJWs3V/pub
Other than not bothing yet with RUNFILES_MANIFEST, which is only needed on
WINDOWS.

The functionality seemed general and simple enough to be worth upstreaming into rules_haskell itself; let me know what you think and/or if there's a better place to put this.

[mboes]

Nice! I think this indeed belongs in rules_haskell. I was about to write this myself.

We like using the handle pattern. Would you find it acceptable to use it here? This would mean:

• Bazel.Runfiles module always imported qualified.
• Runfiles renamed to Handle.
• runfilesEnv -> env (though I'm not sure whether this one should be exported).
• getRunfiles -> create, which would bring the library closer in line with the Runfiles design document you link to, which says languages should define a create() method.

[mboes]

What's the use case for this function? Should users set RUNFILES_DIR when it's not set? It was my understanding that RUNFILES_DIR is set iff the target is a data dependency of another. I don't know about tests.

[judah]

Added clarification in the comment; it's for non-test binaries to set manually, since from my testing it's only set automatically in "bazel test".

[judah]

I switched the module to qualified names and renamed getRunfiles to create. (I'm wondering if create will be more confusing than helpful; because we're not in an OOP language, it sounds like it's actually constructing the symlink tree or something similar. But for now it seems fine.)

I avoided renaming the Runfiles type to Handle, though. My understanding is that the handle pattern is intended for stateful sequences of IO calls that wrap some form of "service". In contrast, a Runfiles is only ever read from disk once, and then remains a pure, immutable Haskell datatype (and all operations on it are pure). For example, there's no need for a close or withHandle function. So I feel it makes more sense to give it its own type name, like a regular Haskell type, rather than make it seem more stateful than it actually is. Let me know whether that sounds reasonable to you.

[mboes]

Agreed. But in that case, create for Runfiles could even be moved out of IO entirely, in which case we could have a plain rlocation with no Runfiles argument. Reasoning being: runfiles are both global and immutable.

In any case, I'm also fine with the current state of affairs.