It should go out on the weekly Friday dev release - 2.7.0.dev1. I won't be around to lobby for cherry-picking to other branches, but you could have that discussion with other maintainers.

I should have the upgrade PR posted here in a few minutes before I disappear into the woods for the rest of the week+. /cc @witty-crayon-22786 and @hundreds-father-404.

I probably won't have connectivity to merge this: https://github.com/pantsbuild/pants/pull/12342

I'll resolve conflicts and merge this one.

@happy-kitchen-89482 I can finish it if you want, you'll need to use the new

./pants --tag=-lock_ignore lock ::

goal

Oh yeah, you should do it

since the conflict is that constraints.txt was deleted

this is your wheelhouse now 🙂

But this means that we can't easily cherrypick

I'll do a dedicated PR for 2.6.x that is not a traditional cherry-pick

https://twitter.com/mateornaut/status/1415089845735772160 Pants Build retweeted: @pantsbuild We are hiring at BlackRock - I don't have a rec open for Python specifically but I would be very eager… https://twitter.com/i/web/status/1415089845735772160 Twitter

Within CI, I'm running tests on changed files (

./pants --changed-since=origin/master --changed-dependees=transitive test

). Some of the code within the repo depends on files stored using git lfs, but most of it doesn't. Right now, we are checking out lfs for every pull request, which generates unnecessary bandwidth. It would be great if (somehow) I could run lfs checkout conditionally - only for tests that need it. Any ideas on how this could be done please? :-)

Is there a way to let pants bootstrap itself without reaching out to the internet? That is, is there a way to pre-download the packages that it will need and somehow distribute them to systems that will need to to run the

./pants

script?

How are teams handling caching of

named_caches

in CI? We added it to the cache but on BitBucket, the cache is only written the first time it is missed. That means if it's written on a CI run that doesn't touch most of the repo it will be fairly incomplete. We used to be on Gitlab where the cache could be updated after each run so it would continuously expand - but then we had the problem that it would eventually grow too big and the cost of downloading it exceeded the benefit. Is anyone implementing their own cache system using something like S3?

Anyone ever come across this before? Python 3.6.12 install via pyenv and 100% available from the PATH. Pants finds it to bootstrap but when it comes to finding interpreters to resolve requirements and run the code it finds nothing… Running Pants

1.30.4

yes i know it is an older version but we are stuck here for the time being

20:46:12 00:00 [main]
               (To run a reporting server: ./pants server)
20:46:14 00:02   [setup]
20:46:14 00:02     [parse]
               Executing tasks in goals: gen -> pyprep -> run20:46:14 [DEBUG] pants.process.lock:pid=16680: acquiring lock: <pants.process.lock.OwnerPrintingInterProcessFileLock object at 0x10e05e6a0>

20:46:14 00:02   [gen]
20:46:14 00:02     [thrift-py]
20:46:14 00:02     [py-thrift-namespace-clash-check]20:46:14 [DEBUG] engine::scheduler: Launching 0 roots (poll=false).
20:46:14 [DEBUG] pants.engine.internals.scheduler:pid=16680: computed 0 nodes in 0.000226 seconds. there are 74 total nodes.

20:46:14 00:02   [pyprep]
20:46:14 00:02     [interpreter]
                   pants_backend_python_tasks_select_interpreter_SelectInterpreter will read from local artifact cache at /Users/distiller/talos/.pants.d/.pantscache/b56378cd3458bce8ae082d0ed362f8bd7ab9795b
20:46:14 00:02       [cache]
                   No cached artifacts for 2 targets.
                   Invalidated 2 targets.20:46:14 [DEBUG] pants.backend.python.interpreter_cache:pid=16680: Initializing Python interpreter cache matching filters `CPython>=3.6,<3.7` from paths `/Users/distiller/.pyenv/versions/3.6.12/bin:~/.pyenv/versions/3.6.12/bin:/Users/distiller/.pyenv/shims:~/.pyenv/versions/3.6.12/bin:/Users/distiller/.pyenv/shims:/Users/distiller/.pyenv/shims:/Users/distiller/.gem/ruby/2.7.2/bin:/Users/distiller/.rubies/ruby-2.7.2/lib/ruby/gems/2.7.0/bin:/Users/distiller/.rubies/ruby-2.7.2/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin`
20:46:14 [DEBUG] pants.process.lock:pid=16680: acquiring lock: <pants.process.lock.OwnerPrintingInterProcessFileLock object at 0x10e0c2908>
20:46:14 [DEBUG] pants.process.lock:pid=16680: releasing lock: <pants.process.lock.OwnerPrintingInterProcessFileLock object at 0x10e0c2908>
20:46:14 [DEBUG] pants.backend.python.interpreter_cache:pid=16680: No valid interpreters found for CPython>=3.6,<3.7!
20:46:14 [DEBUG] pants.backend.python.interpreter_cache:pid=16680: Found no valid interpreters!
20:46:14 [DEBUG] pants.backend.python.interpreter_cache:pid=16680: Initialized Python interpreter cache with
20:46:14 [DEBUG] pants.backend.python.interpreter_cache:pid=16680: Initializing Python interpreter cache matching filters `CPython<3:CPython>=3.3:PyPy` from paths `/Users/distiller/.pyenv/versions/3.6.12/bin:~/.pyenv/versions/3.6.12/bin:/Users/distiller/.pyenv/shims:~/.pyenv/versions/3.6.12/bin:/Users/distiller/.pyenv/shims:/Users/distiller/.pyenv/shims:/Users/distiller/.gem/ruby/2.7.2/bin:/Users/distiller/.rubies/ruby-2.7.2/lib/ruby/gems/2.7.0/bin:/Users/distiller/.rubies/ruby-2.7.2/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin`
20:46:14 [DEBUG] pants.process.lock:pid=16680: acquiring lock: <pants.process.lock.OwnerPrintingInterProcessFileLock object at 0x10e0c2400>
20:46:15 [DEBUG] pants.process.lock:pid=16680: releasing lock: <pants.process.lock.OwnerPrintingInterProcessFileLock object at 0x10e0c2400>
20:46:15 [DEBUG] pants.backend.python.interpreter_cache:pid=16680: No valid interpreters found for CPython<3!
20:46:15 [DEBUG] pants.backend.python.interpreter_cache:pid=16680: No valid interpreters found for CPython>=3.3!
20:46:15 [DEBUG] pants.backend.python.interpreter_cache:pid=16680: No valid interpreters found for PyPy!
20:46:15 [DEBUG] pants.backend.python.interpreter_cache:pid=16680: Found no valid interpreters!
20:46:15 [DEBUG] pants.backend.python.interpreter_cache:pid=16680: Initialized Python interpreter cache with
20:46:15 [DEBUG] pants.process.lock:pid=16680: releasing lock: <pants.process.lock.OwnerPrintingInterProcessFileLock object at 0x10e05e6a0>

FAILURE: Unable to detect a suitable interpreter for compatibilities: CPython>=3.6,<3.7 (Conflicting targets: apps/cli_clouddev/src:clouddev)

Pants detected these interpreter versions on your system:

Possible ways to fix this:
* Modify your Python interpreter constraints by following <https://www.pantsbuild.org/python_readme.html#configure-the-python-version>.
* Ensure the targeted Python version is installed and discoverable.
* Modify Pants' interpreter search paths via --python-setup-interpreter-search-paths.

https://twitter.com/pantsbuild/status/1415831674080858115 🤣🤣🤣 Twitter Beginning Rust: Uh why does the compiler stop me from doing things this is horrible Advanced Rust: Ugh why doesn't… https://twitter.com/i/web/status/1412536312150716416 Twitter

is it possible to run

./pants tailor

on a subset of the source tree.. ?

It is now!

Not documented yet (and I'm not sure if it's released yet, let me check)

Say, questions about dependencies. I have a project with two subprojects (libraries), say A and B, with subtrees of BUILD files. Each have their own requirements.txt files, with a fair amount of overlap (call the requirements a,b,c, whatever). And that means that a lot of the A library files generate the dreaded "The target A/foo/bar imports 'a', but ... it is ambigious which to use: ['A:a', 'B:a']" messages. I can resolve this by declaring each "A:a" in dependencies, but that's a lot of dependencies in a number of BUILD files under A, when I feel like there should be a way to say that "All the BUILD files under A should draw their dependencies from the

python_requirements

under A and not elsewhere in the project"

Does anyone have a good solution with

./pants package ::

to block CI when a release version for a changed package already exists? (eg, if I change a package and do not update the version number I would like to see a failure).

So, I was chatting with @busy-vase-39202 about incremental pants adoption in existing repos. The

skip_pylint

and

skip_*

parameters are really helpful, but I had to add them manually wherever I wanted to skip them. (PS -

skip_*

is a lifesaver. Thank you!!!) For existing projects that want to adopt pants incrementally, what if you could add a "skip by default" mode to

./pants taiilor

? Then, someone could go in and un-skip the tools in just one directory, and slowly increase the number of enabled directories until they've linted everything. Heck that would be a pretty cool way to adopt

black

and other tools more incrementally as well. That would give great flexibility for very small POC pants implementations in existing repos to show the value pants provides before adopting it in more and more of the repo until the entire repo can be covered by pants.

Hi there, what is the option

execution_mode = "venv"

used for when building a PEX file? Is it used to unzip the PEX file when it is executed? Thanks

Hi team, when having this configuration:

[python-setup]
interpreter_constraints = ["CPython==3.6.*", "CPython==3.8.*"]

will Pants always pick up the Python

3.6.*

if both

3.6.*

and

3.8.*

are available? I’ve read that the comma separated versions would be representing the

OR

constraint, so if 3.6 is found (even if 3.8 is present as well), it will be used, but just wanted to double-check.

@hundreds-father-404 sorry its taken me a bit to check back here. finally had the time. Any updates here? did this go out in the latest 2.6 release??

Hey @salmon-barista-63163, it has not yet - the Pex upgrade causes some tests to fail and I haven't had time to understand yet what's going on But in the meantime, there's a workaround. Change the

version

and

known_versions

options for https://www.pantsbuild.org/docs/reference-download-pex-bin to these values https://github.com/pantsbuild/pants/pull/12342/files#diff-de25cbd33fc6fadd662c74dd4f16dbc6dc901f58204950751d6363f2bbc5df6a

When pants resolves the constraints file? Does it currently rely on the pip cache for things, or does it have its own system for knowing when things have changed? It seems to take a long time to resolve a lot of the time. We are using our own pipy mirror, which might not be responding with the correct Etag for the artifacts wondering if that could be the cause.

Thanks @hundreds-father-404 ill do this and test it out.

I observe

coverage.py

behaving in a weird way when running tests. It’s being confused about sources for some code:

pants.engine.process.ProcessExecutionFailure: Process 'Generate Pytest xml coverage report.' failed with exit code 1.
stdout:
No source for code: '/private/var/folders/k0/3nssm8v15r5b08k1k1wyhs2r0000gp/T/process-executionzCCweC/(builtin)'.
Aborting report output, consider using -i.

Could we possibly get an option to hide bandit output on success? It will always print to stdout regardless of the process's exit code.