https://pantsbuild.org/ logo
Join Slack
Powered by
ftr: we're seeing tons more network traffic with 1...
# pex
w
ftr: we're seeing tons more network traffic with 1.26.x / pex 2 (about 10x, even with concurrency pinned lower than that)... i'll be spending time tomorrow to investigate that.
đź‘Ť 1
following up on this: it's not clear yet whether this is the client or server. will know more on monday.
@wide-energy-11069’s thread in #lang-python is a continuation of this
@wide-energy-11069: so, regarding https://github.com/pypa/pip/issues/8109 : pex uses a lightly patched pip. if the change looks valid but they are pushing back on it for ideological reasons, it’s possible that @enough-analyst-54434 / @happy-kitchen-89482 would be ok with landing the patch for pex before it lands upstream… having a path to landing upstream would be ideal though
or just ignoring it, i suppose
w
Thanks! I was thinking about that as well. Where in the pex indicates it’s consuming a patched version of pip?
w
would probably want to reframe the issue into a patch though.
pip is vendored in pex.
w
pex uses a lightly patched pip.
Is it using a forked pip?
w
so when it runs pip, it extracts the sources of pip from the pex, and then subprocesses it
yes. “lightly patched” is a politically correct way of saying forked. but it’s also about intent. it shouldn’t diverge from pip very much, or it will be very hard to maintain. needs to stay small.
so, it’s not my decision to make, but i’d suggest that at least having an outstanding upstream patch for the issue would be the minimum requirement for including it in pex.
w
well what we need in this case would involve changing pip, right? It might be different from the patched pip right now which is more of a “wrapper” on pip
w
yes. changing pip.
er, sorry. i don’t know what you mean. pex has more than a wrapper of pip. it has a full copy of the sources. ie, it vendors a patched pip.
w
reframe the issue into a patch though.
meaning converting from feature request to bug fix, or us directly sending over a PR?
w
bug fix / PR, yes.
đź‘Ś 1
e
Probably nice to have the issue to refer to anyway. Like hey we tried the channels
w
w
i don’t know what code implements it.
there is a readme that explains how the vendored copy is maintained, so don’t just start editing.
w
Looks like there’s a good chance the fix can be incorporated into https://github.com/pypa/pip/pull/8078 per https://github.com/pypa/pip/issues/8109#issuecomment-619462705. When it’s merged upstream pip, what would be next step? Does it require pip to publish, then pex bumps its dep on pip? then pants bumps its dep on pex?
w
Awesome news.
Not sure, but I don't think so, since it is vendored. See the readme linked above about the vendoring
w
a
yes, make a PR against pantsbuild/pip, then we re-vendor it into pex
please let us know if any part is unclear ^_^
w
Thanks, Danny. I’ve preemptively created a PR: https://github.com/pantsbuild/pip/pull/7
đź‘Ť 1
a
thanks!!
e
@wide-energy-11069 looking at https://github.com/pypa/pip/issues/8109 I see: "We'd like some mechanism to force the cache TTL for the index page". Can't you just configure your server to return useful cache control headers?
Open in Slack
PreviousNext
Powered by