https://pantsbuild.org/ logo
Join Slack
Powered by
<@UB2J9BQA0>: looks like `gzip` isn’t as common as...
# development
w
@hundreds-father-404: looks like 
gzip
isn’t as common as 
tar
or 
unzip
, so i’m thinking of having https://github.com/pantsbuild/pants/pull/13335 use the Python 
gzip
module
to do that, i’ll need to select a Python in a generic way. we already do for PEX creation, so maybe i should move “bootstrap python” selection out into the core?
heading in the direction of treating both 
bash
and 
python
as scripting environments that we support in the core, basically
h
What's the motivation here?
w
for extracting 
.gz
files?
er, the missing bit is that 
gunzip
isn’t present in our CI environment (although it is on my mac), so i doubt that we should require it for JVM support.
👍 1
h
Hm how do our tests pass for extracting 
tar.gz
files right now?
w
we use 
tar
👍 1
which must use 
gzip
as a library, rather than as a binary
h
Got it. Should this instead be done via the native engine? John has pointed out that it would be better for us to be using Rust for all of 
archive.py
, reduce # of non-hermetic dependencies. Might improve cache hits for desktop builds with remote caching also?
w
the downside of doing it natively would be not caching it, or remoting it
and the same actually goes for downloading things… moving that out of native code into the sandbox would be better for remote execution
if we moved it into native code, we’d have to build a native binary to ship around
👍 1
so, given that: does what i said make sense? lifting Python support out as something to script with? i guess the bar would be “zero thirdparty dependencies”, so we wouldn’t bring PEX out into the core (yet?)
h
Yeah, agreed. And Python 3.6+ plus perhaps? So scripts don't need to worry about Python 2.7 compat (less to test etc)
w
yea
h
Imo, we could update our Pex runner code to stop looking at Python 2, at least by default
👍 1
Open in Slack
PreviousNext
Powered by