Thanks for chipping in Sander !
[...]
> I like the intersection option better. I have a feeling that without
> that, you either end up not doing exceptions because it is too
> tedious to add everything back that you want to build, or, you end up
> with a long list of elements to explicitly build.
So I dont think --except is an option for `bst build`, because well,
building requires what it requires (this might not be entirely true for
`bst --no-strict build`).
I was wondering about this, and you're right. It would be --track-except.
And the edge(?) case of --no-strict, is another one to consider but probably out of scope for this particular issue.
That said I also prefer the intersection option, although admittedly, I
had a hard time explaining what it meant on IRC yesterday, which is not
a great sign.
> I see the use case of the stack element, and the desire to except it
> and all its descendants. However, I also see the case of excepting
> just a single element. Should we introduce the same --except and --
> except-recurse to allow for that flexibility? Or is that too much?
>
> Another path could be to introduce an option that takes a file
> containing all elements to exclude. That file could be produced by
> taking the output of an incantation of `bst show` on an element to
> exclude, if you want to exclude its descendants.
What I want eventually, is to have tracking profiles defined by the
project, and leverage those - usually the project knows what kind of
tracking strategies it wants to employ (I call these profiles because I
think there can be more than one strategy for a given project).
I have to say I'm growing a bit weary of what `bst build --track` is
starting to look like:
--track
--track-recurse
--except
--except-recurse (maybe ?)
It looks like a lot of stuff, then again I like the --except option as
a general way for expressing and filtering pipelines, I'm a bit on the
fence here.
I'm starting to feel that we're overshooting the mark by a bit.
It does look like a lot.
For the current work, I think the wisest will be:
o Lets move forward with the --except changes the way that they are,
for the commands where --except already exists, lets allow
specifying it multiple times and if it's not a point of contention,
lets go with the `intersection` approach.
o Lets do the minimum for `bst build --track`
I feel like we need to handle these cases for 1.0
- Distinguish between saving and not saving
- Allow granular selection, OR, be able to grow it without
having a horrible API
And for GNOME, I need recursive except with recursive track
The use case for GNOME is that I need to run:
bst build --track --track-except base.bst core/meta-gnome-core.bst
I.e. a command line which is simple enough to express that I want:
o To recursively track everything
o Except for the base sysroot, which I dont want to change and
rebuild the world as a result
o To not save the results, leaving my git repo clean
I think the interesting part of this use case is that you are passing in stack elements. And for stack elements it makes sense to recurse, otherwise, what is there to track?
So that the average developer can easily "build the latest all the
time".
I'm afraid that once we grow project defined tracking profiles, most of
this added stuff will become irrelevant - and we'll be left with a
bunch of annoying `bst build` options that nobody needs to use.
What if we just had `bst build --track` be recursive, allowing multiple
occurrences of --track-except on the same command line, each one
recursive and using the `intersection` method.
I think the original issue was exactly that `bst build --track` is recursive, and that there is no way to express you only want to track the element that you are building. But maybe it is ok to `bst track element.bst && bst build element.bst`...
What we actually might be running into is a potential divergence in understanding of what would in a project. Which may or may not be addressed with recursive pipelines.
This is CLI convenience, nobody is going to cook up command lines with
every single element they want to except, so non-recursive seems
unimportant.
Then, we wait until post 1.0 to introduce "tracking profiles" in the
project to declare this in a much more fine grained way, and simplify
the CLI at the same time.
Thoughts ?
The only concern I have is that it is going to be hard to go back and make `bst build --track` non-recursive later. Otherwise I think we're pretty much in agreement.
Cheers,
-Tristan
Cheers,
Sander
