I don't know if it's a known bug but when running the

binary

goal on multiple files, pants don't automatically ignore other goals, works well with the test goal btw

When you glob over files or targets, Pants knows to ignore ones that aren't relevant to the requested goal.

and throws the following error:

ERROR: The `run` and `binary` goals only work with the following target types: ['python_binary']

You used packages-python-pants/helloworld/greet:greet with target type 'python_library'.

Ah, this was fixed yesterday and will be included in the release on Friday

niice, throught I can't think of a use case where it can be usefull, I find it cleaner to have clearly separated

library

and

binary

goals

I agree with you - I like the explicitness. The main use case would be that you’re a new user, that you can run

./pants binary app.py

without needing to manually set up BUILD files

if you don't have to set up a build file, then running

python app.py

will do, if you have dependencies on

3rdparty

, and/or other `python_library`'s you will have to set up a BUILD file anyway, no?

That would be unnecessary because of dependency inference and/or buildgen, meaning that Pants understands your Python code and can figure out all your requirements for you without maintaining a BUILD file. Toolchain has a buildgen service that gets close to this already. It understands all Python imports (crawls PyPI regularly) and will automatically update your BUILD files for you

that and also I'm also all for KISS, keeping it simple and straithgforward is never a bad idea 😁

Agreed, great point. Speaking of which, let us know when you encounter things that are confusing with Pants, especially as you explore V2. It’s especially important that things are simple and intuitive because every engineer at an org interacts with Pants in some way. Even if they might not be the maintainer of Pants at the org, they’ll still run things like

./pants test

and read BUILD files (I try to take the perspective of when I first used Pants ~two years ago as a summer intern at Foursquare hehe. Would this make sense to me as an intern who didn’t know what a monorepo was two days ago?) -- This includes confusing error messages. We’ve been trying to do a better job at not only explaining the what, but also the why and how to fix (where relevant). Still, it’s easy for us to miss some

honesty been using the v1 for a couple of months now, and no complaints, I've initiated interns that were completly new to programming to use pants and they got the idea pretty quick (ofc everything was already set up haha)

Awesome, glad to hear!

actually we have two monorepos in my company, one containing only js code and uses yarn v2, pnp and lerna (I'm not sure about all the details as I don't work extensively on it) for managing the code, and the python monorepo for all data stuff, and since I work on both I get to use firthand the two tools pants and yarn. for me one thing that would be game changing for pants is to remove the need to use a bash script for invoking pants (seems hacky haha), and to be able to run pants from anywhere, for example running

pants test

in

package/data

will run the

python_test

target in

package/data/BUILD

.

Huh, interesting! I don’t think we’ve ever seriously considered that, at least in the past year. It sounds like there are two reasons you’d like this: 1) Be able to run Pants from anywhere in your monorepo - you don’t need to be in the build root 2) Less hacky, e.g. no need to update the bash script when we do things like add

pants.toml

support

Part of what the

./pants

script does is pick the right version of Pants to use.

what we have for yarn is we use yarn v1.22 for example, and if installed yarn.version != 1.22 error out