Add support for views

[tengstrand]

I have the idea to support the concept of views. A view will have a name and a set of bricks and/or projects and will be configured in workspace.edn, e.g.:

  {
   ...

     :views {"myview" {:components ["comp1" "comp2"]
                       :bases ["mybase"]
                       :projects ["myproject"]}
             "stuff"  {:components ["invoicer" "db"]}}
  }

The use case is to make it easier to select a number of bricks/projects when executing the test command, so that instead of typing:

poly test brick:comp1:comp2:mybase project:myproject

...we can type:

poly test view:myview

This example will make more sense when we have support for selecting bricks explicitly when executing our tests, see issue #116.

Now to the question. Is this something that has any value to people? It only makes sense if the set of bricks and projects are used on a regular basis I guess.

I think view is a pretty good name for this, but if someone has a better name or more ideas around this, please add a comment!

[Misophistful]

How would you describe the relationship between a view and a project? In other words, what happens when a view includes different components and bases than its project(s)?

[tengstrand]

The relationship between a view and a project is that the selected project belongs to that view, and implicitly we say that we have selected a specific project for the workspace, either by typing project:p or by adding p to the view v and typing view:v.

When you execute the info command, it will show you the workspace in "two dimensions" where the bricks are horizontal and the projects vertical. You can think of a view as a way of filtering on both the x- and y-axis on the workspace level.

Let's say we have a project p1 that only contains the brick c1 and another project p2 that only contains c2. When running the test command, it will run the tests for the c1 brick from the p1 project, and the c2 brick from the p2 project.

The default behaviour is to include all bricks (when supported!) and all projects (except for the dev project) when executing the test or info command (the third x flag will be affected by the latter). The idea here is to filter on any of these two dimensions.

[Misophistful]

I still don't understand the relationship. If a project has a collection of bricks, and a "project belongs to a view", wouldn't that mean the view inherits its bricks from the project? What does it mean then to specify other bricks in a view, which aren't in its project (as you showed in the "myview" example)?

Related question: in your example you have a view called "stuff", which doesn't have a project, just components. What's the difference between this type of view and a project?

I think it would be helpful to see a real-world example where the combination of a project and are view are both needed to achieve a particular outcome.

[tengstrand]

The bricks and components that are specified in a view are always applied to a workspace as a way of filtering that workspace (think of doing two set/intersect operations, one for the projects and one for the bricks). The bricks and projects that are left, will be selected for the specific operation (the test and info commands in this case).

[cyppan]

I'm all in favor of a way to define groups of bricks to have less verbose testing commands 👍🏻
Regarding the "view(s)" naming, maybe you have a vision for other ways of using those in the future?

[tengstrand]

Now when I think about it, we could also add :profiles, like this:

{
   ...

     :views {"myview" {:components ["comp1" "comp2"]
                       :bases ["mybase"]
                       :projects ["myproject"]}
             "stuff"  {:components ["invoicer" "db"]
                       :profiles ["special"]}}
  }

Maybe it could be used when visualising a subset of the workspace, e.g. when creating tools for different kind of visualisation, I don't know. The main idea is to use it for the test command and therefore also the info command (to view which tests will be executed).

[tengstrand]

I realised that this only specifies what to include from the workspace, not what to exclude, but that could be fixe:

     :views {"myview" {:include {:components ["comp1" "comp2"]
                                 :bases ["mybase"]
                                 :projects ["myproject"]}
             "stuff"  {:include {:components ["invoicer" "db"]}
                       :exclude {:bases ["cli"]}}}

[tengstrand]

I came up with another use case that could be relevant in the future if you have many components in the workspace.
Let's say we have a huge workspace with 500 components, and that you start working on a task in a certain domain where only 100 of these components would be relevant for you (this is at least what you think!). Then you could create a view containing only these 100 components and if the IDE supports it, it could hide the other 400 to make it easier to work with the code (all 500 will still be included in the development project, so that the REPL have access to all of them).