hundreds-breakfast-49010
02/05/2020, 10:15 PMrepl
goal that tries to figure out which language's repl to run based on the targetsrepl-<language-name>
, i.e. explicitly requiring the user to specify which repl they wantrepl-<repl-name>
in cases where there are multiple supported repl programs for a single language./pants repl-ipython ::
and have pants filter out all the targets that are incompatible with a python replrepl-*
to be collapsed into a single entry in ./pants goals
or otherwise have similar option sets, which would mitigate the "potentially large numbers of repl-<something>
goals in the goal list" problem)hundreds-father-404
02/05/2020, 10:26 PM./pants goals
. Because we don’t do that and you must opt in to certain backends, I’m not concerned about how many new goals it introduces
It would be nice to be able to do ./pants repl-python ::
, meaning load every single Python target in the project.
./pants repl ::
doesn’t make sense because which REPL should you use? We couldn’t safely assume anything.
Alternatively, we could do something like ./pants repl --language=python ::
, but if you had to do that every single time then that is a smell that we should have distinct goalshappy-kitchen-89482
02/05/2020, 11:26 PMtest
or run
, where the behavior is well-defined in all cases (I think), it's not clear what ./pants repl ::
should mean in various cases (e.g., what if you have a python target with a dep on a scala target for some reason, or what if you cannot induce the repl type from the language, e.g., you can look at java code in jshell but also in the scala repl, so languagesXrepls can be many-to-many)./pants repl-py
or ./pants repl-ipython
is crystal clear, and you can just ignore the non-python targets in the target set, as you would in any other use of ::
./pants python
./pants ipython
and so onhundreds-father-404
02/05/2020, 11:37 PM./pants ammonite
, ./pants java
. ./pants ipython
, ./pants python
, ./pants jupyter
. I think that makes sense?
Originally I was thinking ./pants repl-python --ipython
or ./pants --ipython-enabled repl-python
, but I think ./pants ipython
is better. It also naturally expresses the mutex, that you can only have one of python
, ipython
, and jupyter
hundreds-breakfast-49010
02/06/2020, 1:26 AMrepl-python
goal, and other types of repl-*
goals would look much like thiswitty-crayon-22786
02/06/2020, 4:14 AMaloof-angle-91616
02/06/2020, 3:45 PM--only
argument like we have with lint
? not sure if that's way off basewitty-crayon-22786
02/06/2020, 5:34 PMhundreds-breakfast-49010
02/06/2020, 7:18 PMrepl
and using an argument to allow the user to select which of several repls they might want--only
though./pants repl --name=ammonite ::
or ./pants repl --name=python ::
./pants repl-ammonite ::
or ./pants repl-python ::
aloof-angle-91616
02/06/2020, 7:19 PM--only
for linting so it might be useful to eventually converge on the same option namehundreds-breakfast-49010
02/06/2020, 7:20 PMaloof-angle-91616
02/06/2020, 7:40 PMand also it would be expected that multiple repls are compatible with the exact same targetswhen would this be the case?
hundreds-breakfast-49010
02/06/2020, 7:42 PMaloof-angle-91616
02/06/2020, 7:42 PMhundreds-breakfast-49010
02/06/2020, 7:42 PMsbt repl
and ammonite
aloof-angle-91616
02/06/2020, 7:43 PMhundreds-breakfast-49010
02/06/2020, 7:43 PMaloof-angle-91616
02/06/2020, 7:43 PMhundreds-breakfast-49010
02/06/2020, 7:43 PMaloof-angle-91616
02/06/2020, 7:44 PMhundreds-breakfast-49010
02/06/2020, 7:44 PMwitty-crayon-22786
02/06/2020, 7:44 PMhundreds-breakfast-49010
02/06/2020, 7:45 PMrepl
goal with optionswitty-crayon-22786
02/06/2020, 7:45 PMaloof-angle-91616
02/06/2020, 7:45 PMbut it can't automatically guess what repl someone wants from the source filesif we have only a single jvm repl (e.g. ammonite), then this does become possible i believe?
hundreds-breakfast-49010
02/06/2020, 7:46 PMwitty-crayon-22786
02/06/2020, 7:46 PMaloof-angle-91616
02/06/2020, 7:46 PMhundreds-breakfast-49010
02/06/2020, 7:46 PMaloof-angle-91616
02/06/2020, 7:46 PMwitty-crayon-22786
02/06/2020, 7:46 PMhundreds-father-404
02/06/2020, 7:47 PMJava is getting its own repl in one of its upcoming releasesalready has it as of Java 9 iirc
hundreds-breakfast-49010
02/06/2020, 7:47 PMwitty-crayon-22786
02/06/2020, 7:47 PMhundreds-breakfast-49010
02/06/2020, 7:48 PMhundreds-father-404
02/06/2020, 7:48 PMI think we should expect that different shops or individual users will have different preferences for one repl over anotherFurther, Pants should be pluggable enough that plugin authors can hook up their favorite REPL easily
aloof-angle-91616
02/06/2020, 7:48 PMhundreds-father-404
02/06/2020, 7:49 PMif we’re willing to do the work to maintain several different repls before we know whether anyone specifically wants to use them, sureNot necessarily that we will be the ones to support multiple REPLs. Rather that Pants has an infrastructure to allow multiple
hundreds-breakfast-49010
02/06/2020, 7:49 PMaloof-angle-91616
02/06/2020, 7:49 PMhundreds-breakfast-49010
02/06/2020, 7:50 PM./pants repl-py ::
and ./pants repl-scala ::
worked right without the user having to figure out exactly which targets are scala-only and which ones are python onlyaloof-angle-91616
02/06/2020, 7:52 PMhundreds-breakfast-49010
02/06/2020, 7:53 PM./pants repl --only=python ::
better, although I'm still not sure if --only
is the best name for that optionhundreds-father-404
02/06/2020, 7:56 PM./pants repl --name
instead of --only
.
--only
works well with fmt
and lint
because those goals usually run all linters, so you are saying only run this one. Here, you should never run more than one REPL at a time. Rather than not one vs. many REPLs, the question is which REPL.aloof-angle-91616
02/06/2020, 7:57 PMhundreds-breakfast-49010
02/06/2020, 7:57 PM--name
is fine by mehundreds-father-404
02/06/2020, 7:58 PM./pants repl --name
is that you would always need to specify the name (unless we try to infer it, which complicates everything). When an option must always be defined, then that’s a smell to be that it should be a distinct goal
./pants ipython
is more discoverable than ./pants repl --name='ipython'
. Naively, I would try running ./pants repl
without thinking to check ./pants help repl
and seeing that I need to define --name
.aloof-angle-91616
02/06/2020, 7:58 PM--name
could be an enum option which could be discoverable in ./pants help repl
?--name
feels maybe more discoverable?hundreds-father-404
02/06/2020, 8:00 PMok, but --name could be an enum option which could be discoverable in ./pants help repl?Agreed, but there is still the friction of needing to know to run
./pants help relp
in the first place. I can’t think of any other goal that requires always passing an option, outside of ./pants login
./pants $goal path/to:target
. Most users would try doing this the first time they run repl
, I suspect. There’s some tension to fail and say “You need to also pass `--name='python'`”aloof-angle-91616
02/06/2020, 8:01 PM--name
default to something reasonable?hundreds-father-404
02/06/2020, 8:02 PMwell, we can always have --name default to something reasonable?What would that be? In a monolingual repo and in a multilingual repo? I’m thinking before any Pants config is set up. This is a brand new Pants user who is just trying out the tool
aloof-angle-91616
02/06/2020, 8:03 PMhundreds-father-404
02/06/2020, 8:04 PM./pants goals
hundreds-breakfast-49010
02/06/2020, 8:04 PMpython
, ipython
, etc. all be top-level goalsaloof-angle-91616
02/06/2020, 8:04 PMhundreds-father-404
02/06/2020, 8:04 PMpants.backend.java
, we won’t show ammonite
as a goal. This is very similar to how we handle setup-py
aloof-angle-91616
02/06/2020, 8:04 PMrepl
goalhundreds-breakfast-49010
02/06/2020, 8:05 PMaloof-angle-91616
02/06/2020, 8:05 PMhundreds-father-404
02/06/2020, 8:05 PMthe only thing we lose doing that is that we’re no longer calling these goals replsIn the case of
ipython
and ammonite
, I think that is totally fine. But I do agree python
and java
are not great. Maybe those are python-repl
?hundreds-breakfast-49010
02/06/2020, 8:05 PMaloof-angle-91616
02/06/2020, 8:06 PMhundreds-father-404
02/06/2020, 8:06 PMI can see a user looking through a list of goals and wondering what “ammonite” is,Keep in mind they will only see
ammonite
iff their repo has pants.backend.scala
registeredhundreds-breakfast-49010
02/06/2020, 8:06 PM./python repl-ammonite <target>
might be a goal that should live "under" a repl-
"meta-goal" in some wayhundreds-father-404
02/06/2020, 8:07 PMhundreds-breakfast-49010
02/06/2020, 8:07 PMhundreds-father-404
02/06/2020, 8:08 PMor if they’re something we want to keep in v2Generally, we decided no. Tasks don’t fit into a V2 world and all options should live in a
GoalSubsystem
or Subsystem
aloof-angle-91616
02/06/2020, 8:08 PMhundreds-breakfast-49010
02/06/2020, 8:08 PMrepl2-python
merged, and we can change exactly what that's called in subsequent workaloof-angle-91616
02/06/2020, 8:09 PM./pants goals
hundreds-father-404
02/06/2020, 8:09 PMallow goals to have some tag (hierarchical?) which means they display in a specific group in the output of ./pants goalsBenjy and I briefly discussed grouping the output of
./pants goals
. I do think that would be very helpfulhundreds-breakfast-49010
02/06/2020, 8:10 PMaloof-angle-91616
02/06/2020, 8:11 PMfmt
and lint
tasks)hundreds-father-404
02/06/2020, 8:11 PMrepl.ipython
(i.e a task scope). We only discussed grouping the output of ./pants goals
aloof-angle-91616
02/06/2020, 8:11 PMhundreds-breakfast-49010
02/06/2020, 8:12 PMrepl.python
as a naming schemahundreds-father-404
02/06/2020, 8:13 PMit’s not clear to me how that could be possible in the v2 modelSame, not possible with the current design and I don’t think there’s a burning need to add it back. Generally, options living on `GoalSubsystem`s and `Subsystem`s seems to work well. For example,
--isort-config
makes more sense to me than --fmt-isort-config
and at the same time --lint-isort-config
aloof-angle-91616
02/06/2020, 8:13 PMhundreds-father-404
02/06/2020, 8:14 PMactually now that I think about it I kinda like repl.python as a naming schemaSo, this would get really tricky with backwards compat with V1. V1 liberally uses that naming scheme, such as
repl.py
and repl.node
. We would have clashes and competing concepts, that in V1 this refers to a task whereas in V2 this refers to a subgoal(?)aloof-angle-91616
02/06/2020, 8:14 PMrepl/py
?./pants goals
could parse the goal name and generate the hierarchical output?hundreds-father-404
02/06/2020, 8:16 PMrepl/pyHm, interesting. I believe it would destroy our `arg_spliter.py`being able to disambiguate between goals vs. specs, unfortunately
aloof-angle-91616
02/06/2020, 8:19 PMArgSplitter
differentiate between repl
and repl:repl
?repl@py
repl>py
repl\py
(not really this one though because of escaping)hundreds-breakfast-49010
02/06/2020, 8:22 PM.
syntax./pants --v2 --no-v1 goals
output 'repl.py` and repl.ammonite
, among othershundreds-father-404
02/06/2020, 8:24 PMrepl.python
is neat.
In today’s world, we currently have repl.py
and rep.node
as real tasks that you can use. ./pants repl.py path/to:target
.
How do you know that ./pants repl.py
is the V1 task but ./pants repl.python
is the V2 goal?hundreds-breakfast-49010
02/06/2020, 8:24 PM./pants --v1 --no-v2 goals
doesn't output any goals with a .
in the namehundreds-father-404
02/06/2020, 8:25 PMright now running ./pants --v1 --no-v2 goals doesn’t output any goals with a . in the nameWhich is exactly the issue. Currently
goal.subname
always means one thing. We would be changing this so that goal.subname
sometimes means a goal and sometimes means a taskaloof-angle-91616
02/07/2020, 1:31 AMhundreds-breakfast-49010
02/08/2020, 12:31 AM-
instead of a .
- repl-py
is not harder to type or recognize than repl.py
, even though I think I like the look of the latter a little better. also we can start out by just making sure to name different repl goals using the repl-*
convention without actually changing any code yetwitty-crayon-22786
02/08/2020, 12:39 AMis not harder to type or recognize thanno one has to type repl.py right nowrepl.py
hundreds-breakfast-49010
02/11/2020, 8:32 AMwitty-crayon-22786
02/11/2020, 3:58 PM