pantsbuild #general

There are maybe 3 variables @mysterious-farmer-45668. Where do you have the ivy cache pointed to, where do you have the pants cache pointed to (if turned on), and is the jenkins workspace nuked between runs / git re-cloned and/or is

./pants clean-all

used.

mysterious-farmer-45668

07/24/2017, 11:02 PM

okay. I will need to set those before I attempt another run

enough-analyst-54434

07/24/2017, 11:02 PM

Or at least know the defaults and implications. The pants cache - if turned on, can be a global location on the host - multiple workspaces sharing, and things should work / be concurrent run safe. Not so ivy - at least out of the box.

enough-analyst-54434

07/24/2017, 11:03 PM

Seeing if we have high level docs about this...

enough-analyst-54434

07/24/2017, 11:06 PM

We don't afaict

enough-analyst-54434

07/24/2017, 11:09 PM

Basically, its probably simplest to tar up the ivy cache dir after a green CI and push that somewhere, pulling it down on the front-end of a CI run:

Copy code

$ ./pants options --scope=ivy --name=cache_dir
ivy.cache_dir = /home/jsirois/.ivy2/pants (from HARDCODED)

This assumes you use the option above to point pants to a workspace-local

--ivy-cache-dir

to avoid concurrency issues.

enough-analyst-54434

07/24/2017, 11:10 PM

We do ~this in pantsbuild/pants `.travis.yml`: https://github.com/pantsbuild/pants/blob/master/.travis.yml#L44

enough-analyst-54434

07/24/2017, 11:11 PM

The difference being

$HOME

on Travis is isolated, and its not without shenanigans on a jenkins slave, thus the need for a custom

--ivy-cache-dir

in your case.

mysterious-farmer-45668

07/24/2017, 11:13 PM

ah okay. my jenkins build has been stuck in ivy resolve for a long long time

enough-analyst-54434

07/24/2017, 11:14 PM

Yeah - hours would not be totally unexpected for a seed run.

most-wire-83210

07/25/2017, 6:43 AM

thanks @rough-minister-58256 for the release. trying to upgrade pex to 1.2.9

most-wire-83210

07/25/2017, 6:44 AM

I got the following error

most-wire-83210

07/25/2017, 6:44 AM

@User uploaded a file: Untitled

-.txt

most-wire-83210

07/25/2017, 6:44 AM

any help will be appreciated

rough-minister-58256

07/25/2017, 7:38 AM

can’t quite tell what’s going on there

rough-minister-58256

07/25/2017, 7:38 AM

if you can repro w/ a simpler pex command, would file a github issue

astonishing-jelly-60479

07/25/2017, 2:53 PM

we’ve seen a pretty dramatic regression in python test performance since upgrading from 1.2.x to 1.3; the [pyprep] section is taking anywhere from 3-10 minutes in-between runs and leads me to believe it’s no longer caching resolved requirements somehow

astonishing-jelly-60479

07/25/2017, 2:53 PM

@User uploaded a file: Untitled

-.txt

astonishing-jelly-60479

07/25/2017, 2:54 PM

we are passing

--python-setup-resolver-cache-dir

to a directory that is shared between the 8 CI worker processes running on each box and is not cleaned out between runs, but maybe that option changed?

enough-analyst-54434

07/25/2017, 3:07 PM

@astonishing-jelly-60479 the

[cache]

in that output is the Pants artifact cache - lower level than the python resolver cache and used to generally cache artifacts from prior runs. You probably don't have caching turned on. Just a sec for pointers....

enough-analyst-54434

07/25/2017, 3:15 PM

Aha - forgot. The new python pipeline doesn't actually do

[cache]

writes, it just uses local invalidation. @astonishing-jelly-60479 I think this is worth filing an issue. The crux looks like its here: https://github.com/jsirois/pants/blob/master/src/python/pants/backend/python/tasks2/resolve_requirements_task_base.py#L43-L50

enough-analyst-54434

07/25/2017, 3:16 PM

The requirements are resolved into a requirements-only pex and that pex is cached, but only in the local pants workspace (under the task workdir under

.pants.d/

. I think the solution is enabling

[cache]

writes.

enough-analyst-54434

07/25/2017, 3:17 PM

@most-wire-83210 @rough-minister-58256 looks like the issue is old setuptools, more details in a bit...

enough-analyst-54434

07/25/2017, 3:18 PM

But the crux from Karthik's snippet is

Copy code

fastbuild/bin/third_party/pex/_pex.runfiles/__main__/third_party/pex/pex/package.py", line 87, in satisfies
    return requirement.specifier.contains(self.raw_version, prereleases=allow_prereleases)
AttributeError: Requirement instance has no attribute 'specifier'

enough-analyst-54434

07/25/2017, 3:23 PM

The issue is described in these 2 spots: https://github.com/pantsbuild/pex/blob/master/pex/version.py#L6-L9 https://github.com/pantsbuild/pex/blob/master/pex/package.py#L84-L87 The version.py setuptools constraint should limit pex to a compatible version of setuptools where

Requirement.specifier

is a valid attribute, but clearly that's no happening somehow. @most-wire-83210 maybe thats enough detail to help you debug further.

most-wire-83210

07/25/2017, 3:23 PM

thanks @enough-analyst-54434 -