`./pants repl` is frustrating that it's hardcoded ...
# development
h
./pants repl
is frustrating that it's hardcoded to default to
python
, even if you do
./pants repl jvm ::
What about, by default, us simply inspecting the "root" targets and choosing based on what is the most common target type? We'd associate target types with REPL implementations We could maybe warn that there was ambiguity and say how you can use
repl --shell=<alterantive>
to change the value
f
should targets for different repls even be mixed?
(say python vs scala)
although scala and ammonite would both claim the same targets
h
the irrelevant targets would be ignored. So if your repo is 80% Python and 20% Scala,
./pants repl ::
would assume you want Python and ignore the Scala targets Maybe log a warning for how you can get it to choose Scala instead
although scala and ammonite would both claim the same targets
Yes so there is a related question: how do we choose which REPL of multiple to use for the language. I think that should get set in your config. So, 1. A user sets up their preferences: IPython > Python, Ammonite > Scala 2. Pants uses those + inspects the "root" targets to infer which REPL you wanted to use You can ignore both those things by explicitly setting
repl --shell=ammonite
concretely,
--shell
would now default to something like
--shell=<infer>
us simply inspecting the "root" targets and choosing based on what is the most common target type?
This scheme biases file-based languages (Python, Scala) over directory-based languages (Go). Maybe we can do something like based on # of directories involved to make it apples-to-apples
f
well if the users asks for targets that are incompatible REPLs (Python vs Scala), then Pants should just error
since it can only run one interactive process, not 2+
h
That's an alternative approach, and dynamically tell you what command to run via
./pants filter
. See https://github.com/pantsbuild/pants/issues/14295, that's what we plan to do with multiple resolves I think it's maybe friendlier to assume what you want with a warning and instructions for how to get the other thing. But unclear to me
I think it's maybe friendlier to assume what you want with a warning and instructions for how to get the other thing
I'm thinking that because if I do
./pants repl src/python::
in Pants, it's pretty obvious to me as a human that I want to open a Python REPL. But we technically have a few JVM and Scala targets there! I would be annoyed if that caused the command to fail