to force pants to not use system python on OSX, we set

$PEX_PYTHON

appropriately. however, when running

./pants lint

, it seems like pants is still picking up system python. is there some other variable to set for that? or some better way of keeping pants away from system python?

Pretty sure this is a known thing, but I forgot the solution: https://travis-ci.org/pantsbuild/pants/jobs/419313666

Errors that seem unrelated to my change, mostly

Error: Could not find or load main class coursier.cli.Coursier

Anyone remember the solution? Is it a cache nuke?

never seen it before, but yes, probably

Hey! I would like to use the latest Yarn release with the Pants Node integration. How would one go about adding new Yarn binaries to Pants?

One more question, in our CI scripts we are doing:

./pants --changed-parent="${COMMIT_ID}" --changed-include-dependees=transitive test

We’ve got a few custom targets where we set

default_sources_globs

It seems like the command I pasted above will not detect changes to files that should be globbed by what we set in

default_sources_globs

. Does

default_sources_globs

work differently than having sources listed in the BUILD file itself?

But what is strange is that when I just do

pants test

then it detects changes to the files globbed by

default_sources_glob

I have a question about pants from a co-worker at foursquare. What is the best way to see the full sequence of shell commands executed by

pants repl

? (Similar to running

make --just-print

for Makefiles.)

cant u use -ldebug?

yep @average-sugar-76469 that works

ldebug prints out lots of stuff, good for debugging 😛

Another option is

./pants server --open

, which shows you every command executed by each pants run since the last clean.

@eager-librarian-15922

./pants help-all | grep yarn

is instructive, if verbose

Basically you can set a different version for each task that uses it, but if you want to set it once for everything then it’s the

version

option under

[yarnpkg-distribution]

in pants.ini.

Oh, but you’re asking about how to upload new versions to the tool repo

one sec

Looks like those are served by us, so I guess you ask a pants committer to upload those new binaries 🙂

And regarding your other question,

default_sources_globs

shouldn’t work any differently from if you had provided that glob explicitly in the target

sources=

definition. If it does, there’s a bug.

@witty-crayon-22786 @incalculable-window-95429 thoughts on that one?

when trying to lint a target I’m getting:

File "/Users/me/repo/.pants.d/lint/python-eval/executable_pex/cc93f1c8a76250dabba753775c83cbece3fa0562/__pants_executable__.py", line 22, in backtrace_to_here
    line_text = tb.code_context[tb.index]
TypeError: 'NoneType' object has no attribute '__getitem__'

I can

binary

the target w/o issue. anyone know what’s going on? I’m guessing there’s some error being thrown, but the reporting of the error is somehow also messing up, and that’s this error I’m seeing?

You could edit

/Users/me/repo/.pants.d/lint/python-eval/executable_pex/cc93f1c8a76250dabba753775c83cbece3fa0562/__pants_executable__.py

directly to work around that. Pants assumes control of .pants.d and won't check for edits - so will re-use the pex with your edit.

hm, seems like it was a combination of a pex that had inherit_path=True and a corrupt installation of a package in my distribution’s site-packages

I don’t understand exactly how my site-packages got to that state or why code_context was None, but at any rate, seems there are some conditions that will lead to tb.code_context and tb.index being null, so failing gracefully in those situations may be warranted

also, ping on https://pantsbuild.slack.com/archives/C046T6T9U/p1535032432000100 if anyone has any ideas; original issue I was trying to solve is figuring out why lints take almost half an hour

Binary download errored, but url is valid

$ ./pants resolve contrib/node/examples/src/node/server-project -ldebug
13:25:12 00:02     [jvm-platform-validate]
13:25:12 00:02   [resolve]
13:25:12 00:02     [ivy]
13:25:12 00:02     [coursier]
13:25:12 00:02     [go]
13:25:12 00:02     [scala-js-compile]
13:25:12 00:02     [scala-js-link]
13:25:12 00:02     [node]
                   Invalidated 1 target.
                     Cannot find npm-shrinkwrap.json. Did you forget to put it in target sources? This package will fall back to inject package.json with pants BUILD dependencies including node_remote_module and other node dependencies. However, this is not fully supported.
                     Removing [u'dependencies', u'devDependencies', u'peerDependencies', u'optionalDependencies'] from package.json for server-project
                     Adding {u'babel-core': '6.22.1', u'babel-cli': '6.22.1', u'mocha': '2.3.0'} to package.json for server-projectWARN] npm does not support frozen lockfile option. Ignored.
DEBUG] binary_request: BinaryRequest(supportdir=u'bin/node', version='v6.9.1', name=u'node', platform_dependent=True, external_url_generator=None, archiver=<pants.fs.archive.TarArchiver object at 0x110ff3150>)
DEBUG] self._allow_external_binary_tool_downloads: True
DEBUG] external_url_generator: None
DEBUG] fetch_request: BinaryFetchRequest(download_path='bin/node/mac/10.12/v6.9.1/node.tar.gz', urls=('<https://binaries.pantsbuild.org/bin/node/mac/10.12/v6.9.1/node.tar.gz>',))
DEBUG] bootstrapped_binary_path: /Users/yic/.cache/pants/bin/node/mac/10.12/v6.9.1/node.tar.gz
INFO] Attempting to fetch node.tar.gz binary from: <https://binaries.pantsbuild.org/bin/node/mac/10.12/v6.9.1/node.tar.gz> ...
DEBUG] in BinaryToolFetcher: url=<https://binaries.pantsbuild.org/bin/node/mac/10.12/v6.9.1/node.tar.gz>, timeout_secs=30
DEBUG] Starting new HTTPS connection (1): <http://binaries.pantsbuild.org|binaries.pantsbuild.org>
DEBUG] <https://binaries.pantsbuild.org:443> "GET /bin/node/mac/10.12/v6.9.1/node.tar.gz HTTP/1.1" 400 None

DEBUG] releasing lock: <pants.process.lock.OwnerPrintingInterProcessFileLock object at 0x113247d50>
13:25:12 00:02       [install]
FAILURE: (u'Error resolving binary request BinaryRequest(supportdir=bin/node, version=v6.9.1, name=node, platform_dependent=True, external_url_generator=None, archiver=<pants.fs.archive.TarArchiver object at 0x110ff3150>): Failed to fetch node.tar.gz binary from any source: (Failed to fetch binary from <https://binaries.pantsbuild.org/bin/node/mac/10.12/v6.9.1/node.tar.gz>: Fetch of <https://binaries.pantsbuild.org/bin/node/mac/10.12/v6.9.1/node.tar.gz> failed with status code 400)', BinaryNotFound(u'Failed to fetch node.tar.gz binary from any source: (Failed to fetch binary from <https://binaries.pantsbuild.org/bin/node/mac/10.12/v6.9.1/node.tar.gz>: Fetch of <https://binaries.pantsbuild.org/bin/node/mac/10.12/v6.9.1/node.tar.gz> failed with status code 400)',))

Any hints as to how to set env variables for a particular

python_tests

target? Either in pants somehow or by being able to provide my own

pytest.ini

?

afaict pytest.ini is discarded

@brainy-answer-80371 currently there’s no good way to do that (maybe because it’s not recommended to do). as a workaround, you can use prep_comand

like

prep_command(
    name = "set_up",
    prep_args = [
        "-n",
        "MY_ENV_VAR=123",
    ],
    prep_environ = True,
    prep_executable = "echo",
    scope = "test",
)