K, well since run uses an exploded pex, comparing the pexes seems like a great place to start

great!

@enough-analyst-54434 what does it mean that if I extract the pex

x

to directory

dir

, then run

python dir/

, it works, but not

./x

?

That usually means some code in the pex is not zip_safe

IE: it assumes it runs on a normal filesystem and not inside a zip

...EG it doesn't use pkg_resources to load files

IIRC django is a classic here, django apps must be pexed up as not zip safe

would https://github.com/pantsbuild/pants/commit/ab5aeeb34512f50fdaf4e01bf005559c3ccbe08d possibly make it un-zip-safe?

oh you mean that the user code itself, but that doesn’t seem to be the variable here

django apps must be pexed up as not zip safe

Is there a flag somewhere to say so?

CI is red on master due to me. Looks like we slurp up broken pyenv shims still in tests asking for 3.6. Fix here: https://github.com/pantsbuild/pants/pull/6469

GoLang + Tests: I’ve got a testdata dir with test fixtures in it, but go_library doesn’t take

sources

. How can I make these available at test time?

The

GoTest

goal only creates a workspace with dependencies that are themselves `GoTarget`s so using an approach with files like so, also doesn’t work:

files(name='foo', sources=...)
go_library(dependencies=[':foo'])

Sounds like a bug / new feature. I can't think of a workaround with the current code.

Hmm, maybe a go_library target in the testdata dir and then a dep on that. The glob for GoLibrary is * so this might work. Not nice though.

@enough-analyst-54434 yeah i had the same thought, it works if you also create a

foo.go

file in the testdata dir (otherwise go_library complains that there’s no go files)

It looks like testdata dirs are a thing down at the go tool level so we should support this.

Hello this is low priority, but can anyone take a look into https://github.com/pantsbuild/pants/pull/5978?

+cc @rough-minister-58256

would recommend rebasing and fixing the merge conflicts so the diff is easier to follow

i'm running this on master, and it seems like an error to not check that the second target exists (it doesn't) -- does this repro for anyone and is this a known issue / a feature?

> ./pants test tests/python/pants_test/option:a
# ...
ResolveError: "a" was not found in namespace "tests/python/pants_test/option". Did you mean one of:
          :options_integration
          :testing
> ./pants test tests/python/pants_test/option:{testing,a}
# ...
 ===== 158 passed, 1 xfailed in 2.77 seconds ======
                     
                   tests/python/pants_test/option:testing                                          .....   SUCCESS
23:25:48 00:12     [junit]
23:25:48 00:12     [go]
23:25:48 00:12     [node]
               Waiting for background workers to finish.
23:25:49 00:13   [complete]
               SUCCESS

i'll just fix it

To clarify, you’re proposing a syntax to cleanly specify multiple targets in the same folder via

{a, b}

? That sounds useful to me! A couple things to think about - are there any goals where this doesn’t make sense to allow multiple targets to run? I can’t think of any, but would be good to check

pants goals

for a sanity check - do we parse and validate all targets first (strict evaluation), or lazily go through each running the goal and then moving on to next target? In your above example, should you get an error about the invalid

a

target right away or only after executing

testing

- how do we enforce you can only do this at the top level of folders path? We don’t want to allow

src/python/pants/{base,bin}:other

, right?

could everyone please hold off on merging anything else to master until 1.10.x is cut? we're expecting the next run to go green, so hopefully only ~45 mins wait

Hey, guys! Can you please clarify one thing about artifact cache. Recently thx to your help I successfully implemented remote artifact cache which drastically improved compilation time especially for CI. Yet there’s one bottleneck left it seems related to different caching on

compile

and

bundle

goals. One might expect that after compilation of

src

folder all necessary artifacts are already created, yet when I

bundle

on one of the subfolders of the already compiled folder it seems like it’s taking some extra time and creating some extra /checking some artifacts. And this extra time seems quite significant. I wonder if it’s something wrong with my setup which causes cache miss or it’s something inherent to

bundle

goal and what can be done to reduce time (in the same sense as remote cache reduces time for compilations)? Also, whatever cache is made when running the

bundle

goal it’s definitely not getting uploaded/downloaded the same way the cache on compilation does

@curved-vase-73456

bundle

does a lot more than compilation, it packs e.g. all the resources that the target depends on into a single jar, including anything specified with the

bundles

keyword argument (e.g. for

jvm_app()

targets). if you bundle a lot of other files into a

jvm_app()

target, just copying and compressing those could take some time. i also don't believe the output of

bundle

is cached, since the output is usually just to a file in the

dist/

directory (which will be created if it doesn't exist). there's no reason it couldn't be, though -- what are you using the

bundle

goal for? if you haven't yet, i'd check out this page on the docsite (https://www.pantsbuild.org/jvm_projects.html#jvm_bundles)

@aloof-angle-91616 I’m using

bundle

goal to create java executables for several different micro services from sources which I run in docker containers, also I’m pretty sure that bundle does compilation and caching as well: -

clean-all

-> compilation of src folder

4:41

-> making bundle for one of the services in sources subfolder

1:53

-

clean-all

-> making bundle for one of the services in sources subfolder

4:36

-> compilation of src folder

0:25

well the compilation will definitely be cached, but the bundling part i'm not sure about

sure, but the caching/compilation part is the one I’m concerned about

possibly related to https://www.pantsbuild.org/3rdparty_jvm.html#managing-transitive-dependencies