Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Straighten out interpreter search path configuration #6849
Previously, a value in a pexrc would completely override the value of the
Note that this slightly changes the previous behavior, in that the default behavior (if no
left a comment
This LGTM from a functional perspective. The only thing I want to call out here is that implicit hermeticity will be broken for pexrc users with the default search path setting if $PATH contains an interpreter that matches target constraints but is an older version than anything set by a pexrc. I think it would be useful to have info level logging if a pexrc is in play and gets undercut by a PATH interpreter during min() interpreter selection, or at least log at a debug level that pexrc and path are being searched for a minimum matching interpreter and you may not be getting truly hermetic behavior. This is a nice-to-have so I'll leave that to you as to whether you want to add it. Thanks!
Dec 6, 2018
1 check passed
FWIW, this broke our internal release candidate due to the path interpreters winning the min selection. Not a problem, but it did highlight the possibility that without knowing about interpreter_search_paths, users can be unsure of what to do. We might want to call out the exact option and setting in the logging to educate users on the behavior change given that there is no deprecation cycle. I can look into that.
I think Twitter is atypical here. Most users, I'm guessing, want as many interpreters as possible to be found, and are relying on their PATH for this. The PEXRC thing is the advanced thing, and I'm not sure anyone outside of Twitter is using it? It's a great way to whitelist interpreters, but it's not Pants 101...