Anyone have thoughts on allowing `./pants run <...
# development
b
Anyone have thoughts on allowing
./pants run <tool_subsystem>
? I want to know what args
black
or
pylint
accepts. Running
./pants run black -- --help
would be AMAZING (Also this could possibly replace
repl
, if we support the REPLs in
run
. Huzzah less goals? I could do this with my own separate
pex_binary
and resolve, but I think we all understand how nasty that it šŸ™‚
w
I could do this with my own separate
pex_binary
and resolve, but I think we all understand how nasty that it šŸ™‚
fairly nasty, yea. but depends on the usecase… if your goal to be identical to what pants does under the hood when sandboxed (identical config detection, identical options, etc) then there is other syncing of options that you’d need to do. if your goal isn’t to be identical to what we do in the sandbox, then you don’t necessarily need an identical version
another way to accomplish this might be to have magical generated tool targets in some namespace
(…still subject to the same ā€œhow similar to the sandbox are we talkingā€ question)
b
Having to duplicate the reqs in my env and re-lock is prohibitively annoying
In this case, if we ran in-repo I wonder if that'd be "good enough" Have to think about src roots. But you can't win them all
w
also only works if the linter doesn’t need thirdparty deps
you know about
./pants lint --only=black
, right?
b
Yeah... actually
./pants lint --only=black --black-args='--help'
might work (no specs)? But is cumbersome Also I'm still thinking about
./pants run [i]python
as a replacement for
repl
for Python
Also,
lint
or
fmt
? technically we're doing neither linting or formatting
w
i’m still not sure that i understand the
black
usecase.
b
It's just an example of a tool I want to run. A better example is
pytest
w
pytest definitely wouldn’t have thirdparty deps though.
b
E.g. what's the pytest arg to filter to a subset of tests
pytest definitely wouldn’t have thirdparty deps though.
Only if we implemented it that way
w
you’d need awareness of which targets are being run to put the appropriate deps in a sandbox
b
Of course, in this case
--help
s a useful use-case
I thought you meant the
extra_requirements
Which are very important for
--help
Again,
./pants test random_file.py -- --help
would probably work, but is a bit of an abuse
@curved-television-6568 who usually thinks alot about the user CLI experience
c
Before diving in, I just want to observe this (ok, rather awkard) cludge:
$ ./pants -ldebug fmt --only=ā€œblackā€ --black-args=--help src/python/pants/bin:bin
And this could be hidden behind a cli alias, then it is just a matter of a lot of debug output before the actual help message… šŸ˜›
b
Yeah I point that out above, but also: • eww • Now do
pytest
šŸ˜‰ • Now do
ipython
šŸ˜‰
coke 1
c
Ah, right (didn’t read the whole thread šŸ˜› )
and +1 on the
eww
šŸ˜‰
b
I'm kinda also hitting this from the (upcoming) Jupyter notebook support. I'ts kind of like a runner and kind of like a repl. I'm kinda wondering if we could run our tools through
run
, would
repl
be as necessary? (We'd need to figure out third party dep handling, but lets not let implementation details stop progress šŸ™‚ )
šŸ‘ 1
c
This one actually touches slightly on this, I think: https://github.com/pantsbuild/pants/pull/13257
šŸ‘€ 1
b
Yeah I think they are in the same vein
It'd be nice to know how this would be possible for running a JVM or Go tool šŸ¤”
šŸ¤” 1
c
Another thing to consider is that dependencies currently only are targets, but what if we could have a dependency on the digest of a tool, then we could populate it into a sandbox for a experimental_shell_command target and do whatever.
😵 1