Redefine the semantics of clean without arguments

[dzamlo]

If you run bloop clean without specifying a project, nothing happen and it return a 0 (success) return code. I would expect that either:

1. bloop prints the same error message as for the compile or test sub command (that would be Required project name not specified for 'clean'.) and return the same return code
2. it cleans all the projects. It's not uncommon for clean commands to clean basically everything.

I think that 1 would the more consistent and less surprising.

Likely related to that issue, the help message for the -p argument of bloop clean is different that the one for the compile and test sub command (it doesn't specify that the remaining arguments are used). It's also not very clear from the help message that clean can work with multiple projects as arguments.

[jvican]

Yes, I've noticed this. This is a misbehavior caused by #590. This was working before, where bloop clean would just clean all the projects.

We need to define what the best semantics are. I think it would make sense to remove the restriction on bloop compile and bloop test to mean compile all the projects or test all the projects (note this cannot be done for run). Do you think this is something useful @dzamlo?

Likely related to that issue, the help message for the -p argument of bloop clean is different that the one for the compile and test sub command (it doesn't specify that the remaining arguments are used). It's also not very clear from the help message that clean can work with multiple projects as arguments.

I'd like to fix this whenever I also implement #575, that will allow us to compile and test several projects in one go. The benefit of this approach is that bloop would compile them in parallel compared to the sequential version bloop compile foo && bloop compile bar.

[jvican]

Ping @dzamlo 😄

[dzamlo]

Sorry for the delayed response.

All the scala project I work on are single projects.This means that sbt will creates two project (the normal project and the test project). Because the test project depends on the non-test one, I can already compile the two project by compiling the test one and there is a single to test anyway.

All that to say that I'm not the more qualified to evaluate the usefulness of that.

With all that said, I think that supporting multiple projects for the build and test command, especially in combination with the "-w" flag, makes a lot of sense.

For the question fo what to do when no project is specified, my first thought was that this should be equivalent to specifying all the projects. Thinking a bit more about that, I'm not so sure anymore. It may be surprising for some users. Also, if one of your test as some side effect that you may not want, there is more risk that you accidentally run it. But, if this is clearly indicated in the documentation and when you run the command, this isn't an issue. So, I'm not really sure, but I thinks having the commands act like if all the project was specified when none are specified is a good idea.

Anyways, I thinks that the clean, compile and test command should do the same thing regarding these questions. Otherwise It would be confusing.

Another think to take into account. If you run bloop test -w with multiple projects. When your modification is supposed to impact only one project, should the only the tests of this project be rerun ? Or all the tests ?

As a side note, you could also get the parallelism by running the two command in at the same time, either with backgrounds jobs (with an & at the end of the command) or using something like GNU Parallel. If the bloop server support that, I haven't tested.

[tues]

I think it would make sense to remove the restriction on bloop compile and bloop test to mean compile all the projects or test all the projects

I would love this. I've been thinking about this many times.

Alternatively, we could add an optional key to project config files, e.g. default: Boolean (None means false). If there was exactly one project with this value set to true, it would be used as the default one. This would then also work for bloop run. Quite similar to how you can run sbt and type compile, test or run without specifying project (and maybe we could automatically extract which project is the default from sbt too?). The only problem I see with this approach is that if we make users add this value manually, then re-generating configuration from build tool plugins would overwrite it, unless we added some special handling for that.

Either way, I'd be happy to work on this one if there are no other volunteers.

[jvican]

I would love this. I've been thinking about this many times.

Even though I was in favor of this some months ago, now I fail to find any good evidence that merits breaking this behavior. 🤔

In which cases do you think the current semantics are problematic? (assuming we fix bloop clean to mean clean all the projects)

[tues]

good evidence that merits breaking this behavior.

Well, typing two words instead of three (one argument less) for the most common task in Bloop (i.e. bloop compile or bloop test) sounds like a significant productivity boost to me 😉

It's true I use Emacs most of the time, so I'm not typing these commands manually, but the thing I love about Bloop is that I can run it right in my shell without any overhead, so when I do that I forget about the project name quite often, being used to how make, sbt etc. work. In fact, I can't recall any tool which doesn't let you just do sometool compile (or even sometool in case of Make) without specifying project name.

If you're worried about confusing existing users, we could probably make it an option.

assuming we fix bloop clean to mean clean all the projects

Regarding bloop clean itself I agree that cleaning all projects is the most intuitive thing (and I think it's less risky than cleaning just one specific project: it's easy to run bloop compile again if needed, it's very annoying to debug issues caused by clean not cleaning everything).

[jvican]

Well, typing two words instead of three (one argument less) for the most common task in Bloop (i.e. bloop compile or bloop test) sounds like a significant productivity boost to me wink

I'm a little bit confused. Isn't your last message endorsing the current behaviour? From your first message I got the idea you wanted to remove the parameter-less versions of the commands.

[jvican]

OK, after a quick chat in Gitter we realized we're in the middle of a misunderstanding.

So we agree that the resolution to this ticket is to make the bloop clean with no parameters clean the whole build (which was the previous behaviour and it's a regression).

Let's open another ticket to discuss how to allow users to modify the default project that is compiled, tested or cleaned when no parameters are passed.

[dzamlo]

Let's open another ticket to discuss how to allow users to modify the default project that is compiled, tested or cleaned when no parameters are passed.

Isn't that the same thing that I suggested in #553 ?

[tues]

Sorry @dzamlo, I didn't see that ticket. Yes, it's quite similar, so I guess we can reuse that ticket - thanks 🙂

We discussed this in Gitter earlier today and came to a solution which should satisfy all needs, I think:
https://gitter.im/scalacenter/bloop?at=5ba395b17dca3065032b6eee
Later today I'll summarise that discussion in the other ticket.