| *** jude has quit IRC | 00:39 | |
| *** hasebastian has joined #buildstream | 05:47 | |
| *** ChanServ sets mode: +o tristan | 07:47 | |
| tristan | juergbi, I think I just had a good idea about the junction jungle | 07:47 |
|---|---|---|
| tristan | What if we said that, a junction could be allowed to *rename* a project when it gets junctioned ? | 07:48 |
| tristan | or at least rename it in the junctioning project and for all of it's reverse dependency projects | 07:49 |
| juergbi | I actually had a similar thought about it as well. however, not sure how we'd properly handle namespacing | 07:49 |
| juergbi | i.e., what name should be chosen by the project to avoid conflict etc. | 07:50 |
| juergbi | that's why I suggested the 'option' approach where selected option values would become part of the junction key (together with the project name) | 07:50 |
| tristan | That could be a matter of convention, but say I wanted to have a "private" or "isolated" junction, I might call it: "{myproject}-internal-{originalprojectname}" | 07:51 |
| juergbi | but that's just for one class of use cases | 07:51 |
| juergbi | ok but if projects have to follow this convention to avoid problems, wouldn't it be better to have an internal/isolated option to let buildstream take care of it? | 07:51 |
| juergbi | and what about the diamond problem here? | 07:52 |
| tristan | That's where it gets interesting :) | 07:52 |
| tristan | So I've been thinking of two approaches here | 07:52 |
| juergbi | if BuildStream does it internally, {myproject} would automatically be different if {myproject} itself was also marked internal/isolated | 07:53 |
| tristan | The first thought I had, was just allow a junction to rename it's project; and then in a diamond case, use overrides to override a project name of a deep junction | 07:53 |
| tristan | but that idea led me to question "what if things get referred to by project name" | 07:54 |
| tristan | you wouldn't want to damage the expectation of being able to address something by project name | 07:54 |
| tristan | unless you did it from the start | 07:54 |
| tristan | The other idea was to say that "I choose to alias this project to a new name, so that from *my* perspective (and reverse dependency project perspectives), it is seen under a new name" | 07:55 |
| tristan | An alias is a bit less straight forward than a direct rename, but provides more flexibility | 07:55 |
| tristan | regarding "referring to things by project name", I was also thinking of something like composite plugins, or templating plugins (plugins which allow expressing more than one element in simplified YAML) | 07:58 |
| tristan | it seems like it would be an interesting thing if we could refer to a dependency as "{project-name}:foo.bst" instead of needing the junction, that would be helpful in WSalmon's "reusing top-level elements" thread | 07:59 |
| tristan | the 'option' approach is interesting, but also presumes that same-option-different-version is an invalid use case | 08:03 |
| tristan | I'd really like something utterly simple which forces the right actor to make a decision and only when necessary | 08:05 |
| tristan | And stay as far away as possible from presuming what is okay to stage together in an artifact | 08:05 |
| tristan | or a build, i.e. if I *do* have different versions of elements from the same project and they are getting staged somewhere in builds, as long as I know about it, I should be allowed to do what I want | 08:06 |
| tristan | This maybe brings back the original "whitelisting" approach as desirable | 08:07 |
| tristan | juergbi, interestingly the aliasing approach gives you the behavior of the "whitelisting" approach (by forcing the toplevel project in a diamond to make a decision to rename/alias), but also gives you the "internal" feature for free (by allowing a project to remove collisions from the equation for reverse dependency projects) | 08:08 |
| *** hasebastian has quit IRC | 08:18 | |
| *** tristan has quit IRC | 08:40 | |
| *** tristan has joined #buildstream | 08:45 | |
| *** hasebastian has joined #buildstream | 09:47 | |
| *** ChanServ sets mode: +o tristan | 09:56 | |
| tristan | juergbi, I threw up a writeup on the list | 09:57 |
| tristan | take your time :) | 09:57 |
| tristan | Just would like to get this hurdle out of the way soonish | 09:57 |
| juergbi | ta, will take a look | 10:44 |
| *** tristan has quit IRC | 10:53 | |
| *** narispo has quit IRC | 11:01 | |
| *** narispo has joined #buildstream | 11:02 | |
| *** hasebastian has quit IRC | 11:05 | |
| *** tristan has joined #buildstream | 11:18 | |
| *** narispo has quit IRC | 11:25 | |
| *** narispo has joined #buildstream | 11:26 | |
| *** narispo has quit IRC | 11:50 | |
| *** narispo has joined #buildstream | 11:50 | |
| *** Amelia5085 has joined #buildstream | 12:24 | |
| *** Amelia5085 has quit IRC | 12:26 | |
| *** aminbegood has joined #buildstream | 15:15 | |
| *** aminbegood has quit IRC | 16:54 | |
| *** aminbegood has joined #buildstream | 17:40 | |
| *** aminbegood has quit IRC | 17:50 | |
| *** narispo has quit IRC | 18:48 | |
| *** narispo has joined #buildstream | 18:49 | |
| *** narispo has quit IRC | 21:13 | |
| *** narispo has joined #buildstream | 21:13 | |
| *** aminbegood has joined #buildstream | 23:01 | |
| *** aminbegood has quit IRC | 23:15 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!