@witty-crayon-22786 Did you work at Google before?

no

They have an internal system called bazel. The open source version is called blaze. It's very similar to pants.

I think you know that already 😄

yep 😃

hola — running up against https://github.com/pantsbuild/pants/issues/4886 w/ pants 1.7.0 and the torch wheel

what’s the best recourse here? is this still an open issue in the latest version of pants/pex? is there any option better than manually constructing a wheel that doesn’t have the issue?

Hi, anyone here has an example of pants build with scala.js projects that link with external Js libraries?

./pants options --cache-read-from=['<http://www.google.com|www.google.com>'] |grep read_from
cache.read_from = ['/home/ahmed/repo/.cache'] (from HARDCODED)
cache.options.read_from = ['<http://www.google.com|www.google.com>'] (from FLAG)

Is the option cache.options.read_from suppresses cache.read_from option?

blargh. sorry... that's an option order issue.

try:

./pants  --cache-read-from=['<http://www.google.com|www.google.com>'] options | grep read_from

instead

(the

cache

subsystem is scoped, so you can set the options differently for each task)

but if you want to set it for "all tasks", you'd specify it as global

Thanks lot ^_^

but also, if you put this in

pants.ini

, that's the difference between putting something in

[cache]

or in

[cache.options]

(where

cache.options

is the cache scope of the

options

task). more info here: https://www.pantsbuild.org/options.html#setting-option-values

where does pants store info about cached test results by default?

we’re running into a situation where running

./pants test

with some --changed-since flags lists test as ‘SUCCESS’ but doesn’t actually run them. which I believe means its caching the ‘success’ result somewhere? but no matter how many cache locations I try to find and clear, it still seems to “remember” cached successes

./pant options | grep cache.test.pytest

will tell you what it is configured to on your machine.

in general, if you want to skip the cache, you can use

--cache-ignore

positionally

ie:

./pants --cache-ignore test $target

would ignore the cache for the entire run (not just test)

while:

./pants test --cache-ignore $target

would ignore the cache for just test

hm, ok. yeah, we’ve tried deleting that dir (.cache for us) and using --cache-ignore in various positions to no avail

the issue also only seems to happen on one particular developer’s branch… trying to repro the problem on a new branch doesn’t seem to work

if you run for exactly the relevant target and pass

--cache-ignore

, do you see a repro?

running for the relevant targets, even without

--cache-ignore

, does not repro

it seems like it’s only using the --changed-since flag that triggers the issue

one other thing is (and this is... blatant, sorry): you should probably enable

--chroot

and

--no-fast

for tasks that you use caching for.

it would only occasionally cause issues, but if you look at the definitions of those flags, not using them could mean that sometimes mixing targets would have different results than not mixing them.

--no-fast

is easier to try, so worth experimenting with in your repo.

Is it possible to print (cached) next to

SUCCESS

message?