When I spawn subprocesses from my

pex_binary

the subprocesses don’t seem to have the same dependencies available. Do I need to manually set something to propagate environments to spawned processes?

When pants needs to install a package with pip, is there any way to get it to look at a local

pip.conf

file? I'll admit I haven't tried this to see what happens yet.

Does Pants have a Please Equivalent of

genrule()

- run a command, that outputs files s part of the build (is that

experimental_shell_command

) or something else?

Anyone know what might cause Pants to start crashing from segfaults when doing any operations involving dependency resolution (packaging, running, dependencies, etc.)? Seems to have started happening randomly. Restarted host / tried different host / reinstalled pants / wiped caches and still keeps happening. Suspecting might be something I did with the universe of requirements / resolve, but can't think what. This is what gdb says of the coredump: Core was generated by `pantsd [/d/d1/user/taymarti/casper/codetree/codetree/src] '. Program terminated with signal 11, Segmentation fault. #0 0x00007ff4c5d4f928 in ?? ()

Hello again, I am having trouble using matplotlib for plotting with a Qt backend when run through pants or a generated .pex file. It looks like matplotlib is not finding other installed dependencies such as PyQt5 and that even when

execution_mode = "venv"

for the target. In particular I get the error

ImportError: Failed to import any qt binding

even though This might also apply for other external matplotlib backends. More details and example code will follow in the thread.

Adding

interpreter_constraints

to some tool config sections in

pants.toml

results in the following error only in macOS, not Linux (a self-built version) -- where both platform uses 2.12.0 and pex 2.1.99. Am I missing something...?:

for the past ~9 days we’ve been seeing an error running Pants only in CI:

ImportError: No module named __pants_df_parser

when it hits, it hits at the beginning of a job during dependency-parsing (we use

--changed-since

) so I don’t think it’s a resource-exhaustion issue. the jobs always succeed on a retry. at this point I’m trying to export more data from the CI jobs as artifacts to help me figure out what’s going on - does anyone have pointers? I’m thinking of running with

--no-process-cleanup

and exporting the

PANTS_LOCAL_EXECUTION_ROOT_DIR

- should I also grab named caches?

Hi, is there any way to run tests in docker container using docker-compose (db, s3 and opensearch in other containers)?

Possible unintended behavior: I noticed that the lockfile Pants generates (and hence the pip friendly lock pex generates) "normalizes" the distribution names (project_name field in the JSON) to lowercase (and maybe other normalizations, not sure). While probably doesn't matter at all to pants/pex, it did lead to an error in one of our related scripts that consumes the pex exported lockfile. Examples are

qPythhon -> qpython

,

Sphinx -> sphinx

, etc. I haven't confirmed, but it's almost as-if it converts the distribution name to the exposed module name (but that would be even more surprising!).

We have some BUILD files that are generated dynamically (by using the contents of other text files which are updated instead). For example, the `python_distribution`o targets peek at a VERSION file in every library project to get the version. Another example is lists of requirements are split into logical categories (a file for each), and then the BUILD file concats them into a single file dynamically to feed to

python_requirements

. With pants*d* these changes are not detected of course (and I guess this demonstrates

open

or other builtin functions are no exception to the rationale for prohibiting imports in BUILD files as they can "easily break Pant's cacheing mechanisms"). I haven't messed with macros yet, but would these two use cases be solved by them? Or is there a way to manually invalidate a file pattern when invoking pants w/ pantsd enabled?

Hi, is there a reason why the

config

option is not supported under

[pytest]

like most other tools?

how do I tell Pants to use a different Python to run itself once I’ve switched the Python to use with

pyenv

? Do I need to delete a venv or something else?

Is there any plan to add support for safety?

About the section for the report files, it would be great to add an example for

pylint

. I could open an issue if you think this is something worth adding...

[pylint]
args = ["--output-format=text:reports/report.txt"]

experimental_shell_command

uses Pants's code generation mechanism. So files it creates are placed in the sandbox of downstream processes that need source files

If you want to see those files, you can run

./pants export-codegen path/to/experimental_shell_command:target

export-codegen

is a goal that runs codegen on the specified targets and exports the output under dist/

It's generally used for debugging, because usually the output of codegen is an input to some other process, and that doesn't require writing out to dist

But if you need it in dist, that's the way

So basically you should be fine with invoking setuptools via pep517 in the non-legacy way, without a setup.py

generated or otherwise

if that doesn't work, I'd consider that a bug

OK. after several tries, I figured out that I have to include both

setuptools

and

wheel

in my

[build-system].requires

list. Otherwise I get errors about

error: invalid command 'bdist_wheel'

. So, I’ve got my metadata in pyproject.toml, with

generate_setup = False

on my

python_distribution

which is working. But none of the metadata from

[project]

is making it into my wheel. Turns out I have to have setuptools 61+ to use that. So, now I’m working on updating my build-system.requires to make that work…

And I can’t use setuptools 61 because I need to target python 3.6 and it only supports 3.7+. OK. well that was fun.

I shall revert back to using setup.py

So, not a pants bug in this case, just me not understanding something new to me. 🙂

Hello, can parallelism be disabled in

./pants test

? It is causing undefined behaviors in Django because the tests are using the same test database.

that us helpful @happy-kitchen-89482 - i sturrgled to work out how to get to the output . was very complicated. this would have been good to be documented somewhere does

Pants

have something similar to

Please

's style of

plz build //path/to:target --shell

which dropped me into a subshell, to inspect the "context" of that code gen, debug it etc

As strongly suggested in the docs, I use a

lockfile

for each tool and use the

export

command to allow my editor (VSCode) to use the same version of the tool that Pants uses for workflows. This works great for most of the tools, except for

pylint

. VSCode complaints that it is unable to import 3rd party packages (

pylint(import-error)

). Take note that Pants

lint

command works as expected. I suspect this is because 3rd party packages are installed in

python-default

venv and not in

pylint

tool venv. Anybody has this problem? I know it is not a Pants problem per say, but more an IDE integration issue...