Generate project view based on args to installer

[lukaszwawrzyk]

The server was simplified to accept project view path as the only argument. This is fine, but it would be very useful to be able to specify flags from command line. I imagine it as command line interface for generating project view. This would give 2 possible workflows (just example syntax):

bazel-bsp install -d _bsp_projects/my-project
vim _bsp_projects/my-project/projectview.bazelproject
// ... put everything into the fule
idea _bsp_projects/my-project

maybe it is possible to first create the file and then point to in while running install, not sure. But anyway, this is not what I am looking for in this issue. Expected scenario is:

bazel-bsp install -d _bsp_projects/my-project --targets //target/a //target/b --directories foo/bar --debug 5009 --bazel-path /usr/bin/bazel
idea _bsp_projects/my-project

The first command would generate the project view at _bsp_projects/my-project according to options and set up bsp server that uses this file.

[abrams27]

do we want to do it? we started moving things from installer to project view #77

and the the usage (for me) seems not very convenient. For example the project view for bazel plugin has only 20 lines (there are more complex) (https://github.com/bazelbuild/intellij/blob/master/ijwb/ijwb.bazelproject) and for providing 20 arguments via command line seems stupid - at the end of the day I would keep in the file anyway (so in the project view file) and paste it into the command line. Also, should we wipe out the existing file content? For me it doesn't seem useful at all

[lukaszwawrzyk]

I think it is a good direction to keep the server configuration in the project view. It will allow to freely edit the project while working on it. But what about the moment of creating the project? For this purpose I want to have command lines flags to generate such file in the right place. Now the workflow is:

1. run install in specified directory
2. by no means open the created seed project as it will import the whole monorepo and you will be wondering why it already took 20 minutes for bazel to bootstrap
3. open the directory with vscode
4. copy default-projectview.bazelproject from .bazelbsp directory and rename it to projectview.bazelproject (thanks to this file you don't have to remember the name anymore)
5. by no means move the default-projectview.bazelproject because the server will fail to start
6. edit the project view to include targets you want to import
7. close vscode
8. open this dir in intellij
9. project is imported

I would like a workflow like this

1. run install in specified directory with specified targets to import, with a simple command
2. You can even use shell expansion like bazel-bsp install --targets //my-target/src/{main,test}/com/example/... -d _bsp_projects/example
3. open this dir in intellij
4. project is imported

Creting new projects that are slices of the monorepo is quite frequent activity.

Similarly for debugging, we frequently create a new project and we want to debug the server. It is much easier to run command like:

bsp-install -d bsp_projects/my-proj23 -x 5009 --targets //server/...

instead of

bsp-install -d bsp_projects/my-proj23

and don't forget to copy the file from previous project with target specs and debugging configuration.
Also adding debug config is harder as you need to remember the names of options in the project view as we have no coding assistance for such files yet, but we can have bsp-install --help easily.

[abrams27]

In general I would like to add one parameter to the installer - path to project view which would be passed to the server

also, we would like to add (somehow) support for BUILD, WORKSPACE and .bazelproject files syntax support

so, in the new client there would be a mechanism to perform some actions before importing projects with known build tools (currently it is the case for set) - user doesn't run the bsp server manually - the client does it, only for a "generic" case (for not known build tools) user would have to run the server manually and run a "generic" import in IntelliJ. In intellij for bazel we would implement such thing as well, which would include the step where the user can specify a path to project view or create a new one in the popup window (with syntax support)

I think it is a good direction to keep the server configuration in the project view. It will allow to freely edit the project while working on it. But what about the moment of creating the project? For this purpose I want to have command lines flags to generate such file in the right place. Now the workflow is:

1. run install in specified directory
2. by no means open the created seed project as it will import the whole monorepo and you will be wondering why it already took 20 minutes for bazel to bootstrap

(more like 2000 minutes than 20)

3. open the directory with vscode
4. copy default-projectview.bazelproject from .bazelbsp directory and rename it to projectview.bazelproject (thanks to this file you don't have to remember the name anymore)
5. by no means move the default-projectview.bazelproject because the server will fail to start

well, we can't move aspects.bzl as well since the server will fail as well

6. edit the project view to include targets you want to import
7. close vscode
8. open this dir in intellij
9. project is imported

I would like a workflow like this

1. run install in specified directory with specified targets to import, with a simple command
2. You can even use shell expansion like bazel-bsp install --targets //my-target/src/{main,test}/com/example/... -d _bsp_projects/example
3. open this dir in intellij
4. project is imported

Creting new projects that are slices of the monorepo is quite frequent activity.

afaik, on daily basis when u work with mono repo you are just using predefined projective file for you team - you are just specifying the path to the project view during installation, and that's it

Similarly for debugging, we frequently create a new project and we want to debug the server. It is much easier to run command like:

bsp-install -d bsp_projects/my-proj23 -x 5009 --targets //server/...

instead of

bsp-install -d bsp_projects/my-proj23

and don't forget to copy the file from previous project with target specs and debugging configuration. Also adding debug config is harder as you need to remember the names of options in the project view as we have no coding assistance for such files yet, but we can have bsp-install --help easily.

if you are creating a new project you are creating new files anyway, so why not create one more - project view

[lukaszwawrzyk]

In general I would like to add one parameter to the installer - path to project view which would be passed to the server

+1 on that. From the server perspective it is nice to have an argument as project view path and use it as source of truth. Such file is easy to edit later during work with the project. I propose a wrapper that would be a part of the installer that is able to generate project view from command line and later pass this file to the server.

also, we would like to add (somehow) support for BUILD, WORKSPACE and .bazelproject files syntax support

so, in the new client there would be a mechanism to perform some actions before importing projects with known build tools (currently it is the case for set) - user doesn't run the bsp server manually - the client does it, only for a "generic" case (for not known build tools) user would have to run the server manually and run a "generic" import in IntelliJ. In intellij for bazel we would implement such thing as well, which would include the step where the user can specify a path to project view or create a new one in the popup window (with syntax support)

It is a nice idea, I was also thinking about this - to have proper support for BUILD files and some potential custom actions. But regardless of that, one of the first things we implemented for google's plugin was a command line mini-tool to generate seed projects with specified set of targets and open idea. Generally we want to support both GUI and CLI workflows.

(more like 2000 minutes than 20)

Yes, after 20 I just started to be suspicious :p

well, we can't move aspects.bzl as well since the server will fail as well

True that. I initially didn't know the purpose of this file, as it could be handled without visible files. I though it may be there just as an example to copy and use, for convenience. This is the UX thing to think through. With 1000 developers some of them may fall in such trap as well.

afaik, on daily basis when u work with mono repo you are just using predefined projective file for you team - you are just specifying the path to the project view during installation, and that's it

I also heard that it is common approach for bazel world, but other workflows also are possible. In pants projects were created frequently ad-hoc, some people prefer more focused imports, some want the whole project. There is also IDE performance tradeoff. Projects are often big and users select their parts in different variations and it might be matter of personal preference. I know some projects have a script in repo that imports the important targets (and this could be replaced with commited projectview file), but it is not true for most of the projects. Also frequent workflow with bazel plugin is to have some root projectview and use include to take what is wanted. Anyway, the workflow of creating projects from the command line in our use case is a must, and if it will not be the part of official installer, we will have a wrapper.

if you are creating a new project you are creating new files anyway, so why not create one more - project view

Creating a new project in bazel sense is rare thing. If someone wanted to have .projectview for each project, what you are saying of course makes sense. However creating project in intellij/bsp sense is more common. If something doesn't work it is common to just (paraphrasing existing commands):

rm -rf _bsp-projects/my-proj
bsp-install -d _bsp-projects/my-proj --targets //my/targets/...
idea _bsp-projects/my-proj

It is also common to have multiple such projects that include targets in arbitrary combinations. The project in intellij/bsp sense is lightweight and self contained, easy to remove, easy to create. It is different from project in bazel world.

[abrams27]

if there is a use case for that then lets do it

I was thinking about creating a proper tool similar to bazelisk - #179

then we could create an installer - it just create a json file and prepare the environment for the server, and the tool to create a project view and save it in a provided location - everything would be included in this tool (probably user would need to install it on the machine with coursier instead of calling the installer directly using coursier

[lukaszwawrzyk]

I like the idea of this tool. We should explore what coursier can do. I think coursier can prepare a small bootstrap script that downloads coursier and all deps and runs the actual tool. We could even commit such file to the repo, similarly to gradlew.

[abrams27]

this issue contains 2 subtasks:

• updating installer - adding new flags:

  • -t, --targets flag (takes list)- targets section
  • -f, --build_flags (takes list) - build_flags section
  • -i, --include (takes list)- include statement (https://youtrack.jetbrains.com/issue/BAZEL-39)
  • -b, --bazel_path (takes one value)- bazel_path section
  • -x, --debugger_address (takes one value) - debugger_address section
  • -j, --java_path (takes one value) - java_path section

  adding -p flag if there is no generation flag, allows specifying a path to project view file, if there are generation flags (listed above) it means that this generated file will be saved in this place

• creating a mechanism to generate a project view file basing on a project view class: