Should we make `find_binary` uncachable? It relies...
# development
h
Should we make
find_binary
uncachable? It relies on the external state on the machine, and things will break if suddenly a certain binary is no longer available at the original path. Or if you added a new binary and want it to be recognized
h
makes sense to me
although we're starting to add quite a few uncacheable rules while still technically having that annotation as a private api
f
would you hash the contents of the binary?
h
BinaryPaths
only finds the path to the binary, rather than the actual binary. But maybe it should store a private hash! That would properly fix the issue that motivated me to make this change and that I didn’t actually fix Here’s the dataclass:
Copy code
@dataclass(frozen=True)
class BinaryPaths(EngineAwareReturnType):
    binary_name: str
    paths: Tuple[str, ...]
@fast-nail-55400 Greg and I are discussing your proposal more about hashing the contents of the binary. I think it makes a lot of sense. However, lots of paths are symlinks, like
/Users/eric/.pyenv/shims/python3
. Calling
shasum
on it is always the same value. We would need to follow the symlink to get the actual binary. Can you think of any issues with doing that?
f
and with pyenv, all of the shims have the same content
same shim … just forwards to a helper script
😢 1
h
ah, that's troublesome
h
Well that’s sad. Even tho Pyenv would still be broken, do you think it’s still a good idea to hash the binaries and to follow symlinks? Or maybe only hash the binaries but don’t follow symlinks
f
you can
pyenv which python
to have it print out the path
(and also
pyenv which python3.7
etc.)
not sure how linked to pyenv you want this to be
h
I was going to say that generally this can’t be linked to Pyenv, but actually I think we can add that extra logic for our
PexEnvironment
abstraction which finds the interpreters by calling the super generic
BinaryPaths
rule We need a way to identify if it’s a Pyenv interpreter or not, though. I’m not sure how complex to go here. I do think that
pyenv global
not causing Pants to change behavior is pretty confusing for a user
f
the versions selected by
pyenv global
are stored in
$PYENV_ROOT/version
👍 1
(not to be confused with the plural which is a directory e.g.
$PYENV_ROOT/versions/VERSION
)