https://pantsbuild.org/ logo
Join Slack
Powered by
Hi! I'm trying to figure out if it's possible to g...
# general
r
Hi! I'm trying to figure out if it's possible to get pants to use a .netrc file for a private pypi repo? We currently have e.g. a .pants.rc to specify the repo and auth, which works fine but it would be nice to have a single place to refer to (since e.g. other projects use pip direct) for auth, and include the repo path without the auth within the pants.toml
👋 1
e
It should be, and it should be automatic. Please provide copious details if you find this not to be the case.
r
🤔 didn't seem to be working but will check again and detail if not! I wondered if the --isolated would then be switching that off
e
Pex itself handles .netrc above the Pip layer and plumbs through; so Pip being --isolated is not the blocker you'd otherwise expect.
I could definitely be wrong there though! It may best to dump the details in an issue and I can take a look.
f
[flipping over from my ‘personal’ slack to work one 🙂] Thanks, will do. It’s quite possible something isn’t quite right on my setup here, after trying to reproduce breakage with other problems people were having 😅 I had come across the mention in pants v1 of usage of .netrc but couldn’t find anything in v2 hence wondering if that was expected.
😅 I think [unless I’ve gone off on one] I’ve figured out what was happening, I was getting some strange/unexpected results. pants does seem to use the 
.netrc
file for auth ok 👍 Two causes for my confusion: • me trying with good/bad auth resulted in some temporary/partial blocks from our PyPI so it failed and appeared to not use the good auth when available 🤦‍♂️ • when then trying a negative test, removing the auth I had some weirdness with pants caching, even after removing the .cache/pants dir I still was able to use existing cached libs - until killing the pantsd (which I did not know was there 🤔 )
I don’t quite get the second one, it seems really odd… delete the .cache/pants dir and it will bootstrap again but still able to use something from the cache but when pantsd is killed it’s then gone? 😮
e
Yeah, so pantsd basically runs a bunch of python pure functions (@rules) to produce results and execute your build. The result of subprocesses are cached to disk between runs (
.cache/pants/lmdb*
) but the result of all functions calls (@rules) are also memoized for the life of a single pantsd run in-memory. So, while pantsd is up and running Pants caches the most steps possible. It had already done a resolve with auth so it did not try again since it does not track the 
~/.netrc
file outside the repo.
f
👍 that makes sense, thanks for confirming Seems all is ok apologies for the noise! 🙂 A few points to add to our FAQ for next time!
e
Nope, that's ok. There is really a bug here, Pants should track the 
~/.netrc
ideally, but its a 3rdparty tool (Pip via Pex) that reaches out and reads that file; so Pants would have to know about that reach-behind (which it does since we're talking about it!), and do something about it. Currently Pants has the idea that it only tracks files in the subtree its being used in somewhat baked in (IIUC / IIRC); so this is a bit of work / new ground.
Basically this is a bug in Pants sandboxing - it is not complete. If sandboxing were complete and the Processes it ran were truly isolated from your system, auth would fail fast since 
~/.netrc
would not be available (until that dependency were made explicit, in which case pants would track the file and this staleness bug would no longer exist).
👍 1
2 Views
Open in Slack
PreviousNext
Powered by