https://pantsbuild.org/ logo
#general
Title
# general
r

rapid-crayon-8232

04/15/2020, 5:51 PM
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:
Copy code
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'.
h

hundreds-father-404

04/15/2020, 5:52 PM
Ah, this was fixed yesterday and will be included in the release on Friday
Related: one of the neat things that is now possible thanks to V2 is that we can be much smarter in figuring out what you are trying to do. If you have a file called
helloworld/app.py
, but its owning target is a
python_library
instead of
python_binary
, we could make a change so that we allow Pants to figure out if it can convert that library into a binary by doing things like looking if the source file has a
__main__
function. It’s not yet confirmed we want this. It could be confusing to people and there’s an argument that we want the explicitness of creating a
python_binary
target. But it’s now at least possible to do
r

rapid-crayon-8232

04/15/2020, 6:07 PM
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
👍 1
h

hundreds-father-404

04/15/2020, 6:09 PM
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
r

rapid-crayon-8232

04/15/2020, 6:12 PM
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?
h

hundreds-father-404

04/15/2020, 6:16 PM
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
But, yes, I still bias strongly towards needing to use
python_binary
even with buildgen and/or dependency inference. Constraints are ironically liberating, such as the Paradox of Choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice. It’s less cognitive overhead if you can only run
./pants binary
on binary targets, rather than thinking “wait now I can run this on libraries too?”
r

rapid-crayon-8232

04/15/2020, 6:34 PM
that and also I'm also all for KISS, keeping it simple and straithgforward is never a bad idea 😁
💯 1
h

hundreds-father-404

04/15/2020, 6:41 PM
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
r

rapid-crayon-8232

04/15/2020, 6:46 PM
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)
💯 1
h

hundreds-father-404

04/15/2020, 6:46 PM
Awesome, glad to hear!
r

rapid-crayon-8232

04/15/2020, 6:56 PM
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
.
👍 1
h

hundreds-father-404

04/15/2020, 6:59 PM
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
h

happy-kitchen-89482

04/15/2020, 7:08 PM
Part of what the
./pants
script does is pick the right version of Pants to use.
We could figure out another way to do that
But the naked
pants
binary on your PATH would still have to do something like that
👍 2
We deliberately don't want to have a global PATH binary called
pants
that enforces a specific version.
We feel pretty strongly that the version should be fixed by the repo.
👍 2
r

rapid-crayon-8232

04/15/2020, 7:11 PM
what we have for yarn is we use yarn v1.22 for example, and if installed yarn.version != 1.22 error out
and the version of yarn is configured in a config file at the root
4 Views