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