Ok. I was able to solve it by using the patter we had before. I made a wrapper script (

pant3

) that sets

PANTS_WORKDIR

to a different directory then the one in

pants.ini

.

Since this solves my current problem, I am going to refocus on getting to v1.30.0. At which point I will spend more time on this issue. 😵

Should I be able to update

interpreter_constraints

without having to change the

pants_workdir?

Yes, you certainly should be able to. This is buggy behavior. That workaround is not at all satisfying, but it sounds like it’ll work for y’all for now? Trying to get to 1.30 sounds great. This type of thing shouldn’t be an issue with the V2 engine, and generally the Python support is much better

I can see this being useful for other users, so we'd definitely welcome the contribution. There are complications though. E.g., if we go the

!!

route, does that mean "don't bring in this dep through this target"? Or "don't bring in this dep through any target'? Maybe the

!!

has to be on

python_binary

or other root targets, and it means "strip this dep from the transitive closure when computed on (but not through) this target"?

Agreed we’d need to answer that question. Expecting it to be on a “root” target—i.e. a target with no dependees—is tricky to implement, though. There is nothing enforcing that no one depends on a

python_tests

or

python_binary

target, outside of convention. The best thing I could think of to try our best to enforce that

!!

is only used on roots is to have plugin authors express if it’s supported in the Target API. When defining a Dependencies field for their target type, they could set a class property `supports_transitive_excludes = True`:

class PythonBinaryDependencies(Dependencies):
     supports_transitive_excludes = True

If this is set to the default of

False

, then we’ll error if any values in the

dependencies

field start with

!!

.

I’ll be working on this issue today 🙂 I realized last night that it wouldn’t be as simple to “swap-in” your custom rule for

binary

than I hoped. And we think other users indeed may find this useful. @clean-night-52582 if you have a moment, could you please ack if https://github.com/pantsbuild/pants/issues/10661#issuecomment-677793120 sounds on the right track?

hey I’m super new to monorepo and tooling like

pants

so I was wondering what’s the “recommended” way of doing a build docker image process. Right now I have my CI set to

lint

and

test

using the

--changed-since

flag and it works great. Now I’m adding the

bundle

step and that will generate the

.tar.gz

files that will then be added to a docker image. I’m wondering how I can “know” what dockerfiles should be built based on the projects that were actually bundled during the

bundle

step, I can probably do a bash script that gets the output from

dist

folder but is that what I should be doing or pants have some cool feature to trigger commands/scripts that I’m missing?

Sounds great. Commented that on the issue

Great! I’m hoping to get it into the alpha0 release we’re planning for tomorrow. So far no hiccups in implementing it, beyond getting pulled to another priority

That’s awesome!

we solved this by adding a "resource" dependency from our services to the docker file and adding a tag to the resource

you can calculate all changed service and lookup their dependees and filter by the tag

that’s awesome

I’ll give that a try! Thanks!

All ready 🙂 https://github.com/pantsbuild/pants/pull/10663

Great suggestion, @plain-river-51682. Thanks for sharing! Thales, you may want to use a

files()

target instead. They’re really similar, except a

files()

target won’t be included in things like

binary

and it won’t have its “source root” stripped. It’s designed for arbitrary loose files. Also welcome! What languages are you using with Pants? And what version are you on? Let us know if you have any feedback or we can help with anything!

is there a way to filter output of

./pants list ::

based on target type? For example, I want to get only the python libraries using something like

./pants list --type=python_library ::

. The only thing I could only find in the docs was something like this:

# find external dependecies
./pants dependencies --type=3rdparty <lib-target>

found this in the cli. don't know if it is the correct solution.

./pants list :: | xargs ./pants filter --filter-target-type=python_library

although this does not work for 3rdparty dependencies

are there any integrations/plugins on python binary build for pyinstaller instead of pex? We are using pyinstaller + staticx to deliver our python binaries because pex does not include a python interpreter.

This should work:

./pants filter --filter-target-type=python_library ::

And for third party targets:

./pants filter --filter-target-type=python_requirement_library ::

Thanks @hundreds-father-404! I’m using 1.30.0, only python code for now. I can’t use v2 due to my proxy using a self signed CA Cert, I think you were the one that answered me on a github issue about that so just excited to see that resolved on 2.0 🙂

If you haven’t yet seen it, you may find https://www.pantsbuild.org/docs/project-introspection helpful. I still need to document

filter

- my bad!

thx

Also you can use

./pants filter --target-type=python_requirement_library ::

, rather than

./pants filter --filter-target-type=python_requirement_library ::

. They’re different ways of typing the same thing

I'm having trouble finding documentation on

local_artifact_cache

configuration setting. The only mention I see of it is from 2014 on the dev mailing list. It looks like it is still in the code. In 1.18 we configured it under the

[DEFAULT]

section. Is there a single place that DEFAULT and GENERAL settings get defined in the code? I'm trying to learn how to figure out some of these config settings on my own, but having trouble.

Is there any way to set a dependency in pants (like twine) and use pants to run a "custom" command? Basically I want to build my python library with pants and publish it with twine, but I do not want to define it to another system externally to pants (like pip/pipenv), I want to reuse the pants venv. This is how I do it right now

./pants setup-py my_lib -- sdist
pipenv run twine upload dist/*

and I would like something like

./pants setup-py my_lib -- sdist
./pants twine upload dist/*
# or 
./pants run twine upload dist/*

Hey, is there some recommended way to run a custom build of Pants? I need to add a patch for a specific use case that we have and I´m wondering if there exists an easy way to run a custom build of pants

Which version of Pants are you using? It shouldn't be hard to write a custom goal to run twine. We haven't done it yet because we weren't sure if it was sufficiently generalizable to put in the main Python backend. But you could use it internally for a bit and then upstream it, for example.

Seeking clarification on the "broken until 2.0.0 note" in https://www.pantsbuild.org/docs/target-api-extending-targets