Should we make `find_binary` uncachable? It relies...
# development
Should we make
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
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
would you hash the contents of the binary?
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
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
. Calling
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?
and with pyenv, all of the shims have the same content
same shim … just forwards to a helper script
😢 1
ah, that's troublesome
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
you can
pyenv which python
to have it print out the path
(and also
pyenv which python3.7
not sure how linked to pyenv you want this to be
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
abstraction which finds the interpreters by calling the super generic
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
the versions selected by
pyenv global
are stored in
👍 1
(not to be confused with the plural which is a directory e.g.