<@U6YPB4SJX> from this comment -- is there a benef...
# development
a
@average-vr-56795 from this comment -- is there a benefit to using musl vs providing glibc? if it's more likely to be packageable / runnable on arbitrary linux environments i'm all for it -- i'm just not sure how that fits into the packaging process right now: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1546773452021400?thread_ts=1546739970.015700&amp;cid=C0D7TNJHL
ah -- are you referring to the binaries e.g. in pantsbuild/binaries?
that's Quite Interesting
a
This binary is actually a rust binary we
cargo install
The benefit to static linking there is that we don't need to worry about cache platform issues, and rust makes it easy to do
a
so you can just flip on static linking for deps with cargo? or do the crates need to specifically support it?
the benefits you describe make sense to me
a
Assuming the crates don't have any deps which don't like it (e.g. I imagine the grpcio crate wouldn't like it), you can
rustup target add x86_64-unknown-linux-musl
one time, and then you can
cargo build --target x86_64-unknown-linux-musl
or
cargo install --target x86_64-unknown-linux-musl
and it will do the right thing. (Linux only)
h
@aloof-angle-91616 Can you revert your change? Or do you want to wait until my branch is green with a revert in it and then see if you can figure out an alternative in that branch?
Also, can anyone make head or tail of this engine test failure? https://travis-ci.org/pantsbuild/pants/jobs/476078309
a
ok so we actually had an error internally recently relating to parsing python requirements from a
requirements.txt
and i think that's what's happening here -- and actually, this might mean that the
requirements.txt
is getting truncated? or that what
python_requirements()
converts it into is getting truncated by the engine somehow
(because
; python
is in the requirements.txt)
and i should revert my change, i will push a PR now
a
@happy-kitchen-89482 https://github.com/pantsbuild/pants/issues/6861 << it’s been around for a while, I started looking at it a few weeks ago and couldn’t make any sense of it; will hopefully look at it again soon
(Known flake)
h
ah good
maybe we should @skip it then
a
It happens all over the place
Not one test, but anything which leads to 3rdparty/python/BUILD being parsed
h
ah
blurg
a
this definitely specifically happened with a 3rdparty python requirement specified in a
requirements.txt
internally and i would look into that given that this specific error shows a specific string from that file which isn't in the corresponding BUILD file. i'm fixing the checkstyle thing now but can check after