| *** tristan has joined #buildstream | 05:04 | |
| *** ChanServ sets mode: +o tristan | 05:05 | |
| *** tiagogomes has joined #buildstream | 08:37 | |
| *** tiagogomes has quit IRC | 08:46 | |
| *** jonathanmaw has joined #buildstream | 08:46 | |
| *** tiagogomes has joined #buildstream | 08:48 | |
| jonathanmaw | tristan: I have merge requests at https://gitlab.com/BuildStream/buildstream-tests/merge_requests/3 and https://gitlab.com/BuildStream/buildstream/merge_requests/22 | 09:53 |
|---|---|---|
| jonathanmaw | they seem to be correct, to the limit of my ability to test | 09:53 |
| jonathanmaw | (gnome-system is bootable with those changes, initramfs-gz seems to be an initramfs) | 09:53 |
| tristan | jonathanmaw, I'll take a look... | 09:58 |
| tristan | I have been having a lot of trouble with ostree lately :'( | 09:58 |
| tristan | wrote up here: https://mail.gnome.org/archives/ostree-list/2017-June/msg00011.html | 09:59 |
| tristan | buildstream-tests patch looks much better yes :) | 10:05 |
| tristan | jonathanmaw, I thought we would move all that parsing stuff to the concrete 'script' element itself no ? | 10:10 |
| jonathanmaw | tristan: I understood it as splitting it out into helper methods, so derived classes could choose what to include | 10:12 |
| jonathanmaw | I could move parse_layout into the derived scriptelement class without causing duplication work for myself | 10:13 |
| tristan | jonathanmaw, rather I want the base ScriptElement to provide API to make all script-like elements implementable, and have a powerful 'script' element which leverages all of these features | 10:16 |
| tristan | So for instance... the x86image element would call some API to setup the layout in the way that it needs, and the all purpose 'script' element would parse some yaml | 10:17 |
| tristan | the concrete elements might call some function to append grouped commands | 10:18 |
| jonathanmaw | tristan: I'm not sure what you mean by "the all purpose 'script' element would parse some yaml" | 10:21 |
| tristan | It would implement configure() and understand some configuration loaded from yaml, which it would use to exercise all of the API provided by the base abstract ScriptElement class | 10:22 |
| tristan | jonathanmaw, So basically, this "layout" section in YAML anyway is only ever going to appear in that all purpose script element plugin named 'script' | 10:23 |
| tristan | That YAML configuration is user facing API | 10:23 |
| tristan | The ScriptElement API is plugin-author facing API | 10:24 |
| jonathanmaw | so instead of X86Image writing directly to self.layout, the base scriptelement should be providing methods to set the layout appropriately. | 10:25 |
| tristan | So we probably want functions like ScriptElement.layout_add(Element, destination, scope) | 10:26 |
| tristan | And ScriptElement.add_commands(group_name, command_list) | 10:26 |
| tristan | I didnt notice that but yes | 10:26 |
| tristan | And that should probably be ScriptElement.__layout | 10:27 |
| jonathanmaw | tristan: and instead of settting command_domains in the derived element to identify how the commands are set, that's added by functions called in configure | 10:27 |
| jonathanmaw | ok | 10:27 |
| *** tristan has quit IRC | 11:05 | |
| *** tristan has joined #buildstream | 12:05 | |
| jonathanmaw | tristan: having mulled over your suggestions for layout_add and add_commands, I have some questions. | 12:16 |
| jonathanmaw | 1) in layout_add, what is "scope"? | 12:16 |
| jonathanmaw | 2) It would be simpler to have add_commands take the node, and the group name, because the logic for running the substitutions on the commands isn't trivial | 12:18 |
| jonathanmaw | ok, maybe the second one was more of an observation than a question | 12:20 |
| jonathanmaw | i.e. if I made commands an OrderedDict, then inserting commands under that API would be trivial, but also wouldn't be saving plugin authors much effort | 12:26 |
| jonathanmaw | (e.g. they still have to collect the pre- and post- commands themselves, and do all the substitutions | 12:26 |
| jonathanmaw | ) | 12:26 |
| tristan | jonathanmaw, 1.) That is a good question, I threw it in there because, you should be allowed to stage only all the dependencies of self as Scope.BUILD, but perhaps the API is cleaner if that is just the behavior when layout_add() is never called | 12:29 |
| jonathanmaw | ok | 12:30 |
| tristan | 2.) Still I would prefer if that is not a property of the ScriptElement abstract class | 12:30 |
| jonathanmaw | ok, so there should be convenience functions as well to pull in pre- and post-, and substitute them. | 12:31 |
| tristan | Maybe, if it's that much, we could have an "array of strings parse with substitution" convenience somewhere, if that is common | 12:31 |
| tristan | A convenience function could be fine for that yes, maybe have 2, one for loading the array of substed strings, and another for the pre-/post- thing, if that really is needed | 12:32 |
| tristan | It's certainly nice to save lines of code, but sometimes there is a limit to that, though; e.g. when you are only saving one or two lines of code and the expense is that it's more difficult to figure out what the code is doing, then I usually prefer verbosity | 12:33 |
| tristan | I'm not sure what the pre-/post- thing would look like off the top of my head, and how much sense it would make or how readable the code using that function would be | 12:34 |
| tristan | jonathanmaw, So yeah OrderedDict is a decent data type to store the ordered, named command lists privately on ScriptElement | 12:36 |
| tristan | But | 12:36 |
| tristan | I feel that a set_commands(ordered_dict_of_commands) is not a friendly API for plugin authors | 12:37 |
| tristan | rather, adding commands on a per named-list basis is more comprehensive | 12:37 |
| jonathanmaw | tristan: I was thinking set_commands(node, groupname) for the method which does the substitution and collecting prefixes prefix | 12:38 |
| jonathanmaw | s/prefix$// | 12:38 |
| tristan | Ummm | 12:39 |
| jonathanmaw | but yes, using an OrderedDict internally, and taking the order to run command groups from the order they're added, using add_commands(groupname, commands) works for me | 12:40 |
| tristan | Ok so right now we have substitution stuff on Element | 12:41 |
| tristan | Which is because the element owns the variables (and so is not common with Sources) | 12:41 |
| tristan | We have node_subst_list_element(node, member_name, indices) | 12:41 |
| tristan | Seems to me a natural extension (wrapper) to that would be Element.node_subst_list() (which expects the list to be a list of strings) | 12:42 |
| tristan | This leaves pre-/post- logic as an (appropriately IMO) separate concept | 12:43 |
| jonathanmaw | ok | 12:44 |
| tristan | One need only iterate over the possible names, and do commands = self.node_subst_list(config_node, name) and then self.add_commands(name, commands) | 12:44 |
| tristan | ensuring of course that the names one iterates over are in the order that those names should be executed | 12:44 |
| * tristan notes that the 'indices' param of that is a bit annoying/confusing, but necessary in order to support lists of lists | 12:46 | |
| tristan | possibly that will never be used, though :-/ | 12:46 |
| tristan | Ok so I've determined that the issue I'm seeing (finally I understand that it depends on how I use ostree, whether hardlinks are really enabled) is due to https://gitlab.com/BuildStream/buildstream/issues/19 | 13:55 |
| tristan | So it's not a bug with debian, but rather I'm munging some files because hardlinks | 13:55 |
| tristan | and looking at https://www.stavros.io/posts/python-fuse-filesystem/ as a plausible solution for creating the sandbox with copy-on-write hardlink experience | 13:56 |
| *** xjuan has joined #buildstream | 13:58 | |
| tristan | Ok this is gonna be tricky but nice, I'll have to run a process to do the fuse thing whenever sandboxing in; and that process needs to terminate with the build process if ever it's terminated | 14:06 |
| tristan | can be done with a contextmanager API... with fused_build_directory(real_directory) as fused_directory: | 14:06 |
| tristan | then bwrap mounts the fused directory instead... but; should not be necessary for the /buildstream directory in the case that we're staging sources in there and not artifacts | 14:07 |
| tristan | a bit wild | 14:08 |
| tristan | maybe first try the whole thing over fuse and dont bother distinguishing for the source directory unless performance is effected, but I suspect it would be | 14:08 |
| tristan | long time no see xjuan :) | 14:10 |
| tristan | xjuan, you better come to GUADEC this year :) | 14:10 |
| tristan | haha | 14:10 |
| xjuan | hey tristan | 14:13 |
| xjuan | I think so | 14:14 |
| tristan | I'm counting on YOU ! | 14:14 |
| tristan | hehe | 14:14 |
| tristan | xjuan, I promise an especially good whiskey this year :) | 14:15 |
| xjuan | I am waiting for my sponsorship to be approved | 14:15 |
| xjuan | for some reason flights are crazy expensive this time of the year | 14:16 |
| tristan | can't find an excuse to get your company to pay ? | 14:16 |
| tristan | well, I think you will make it some way or another :) | 14:16 |
| *** persia has quit IRC | 14:17 | |
| xjuan | $2200 compared to 1400 early this year | 14:17 |
| xjuan | I think we spent most of the travel budget for this year | 14:18 |
| tristan | ouch | 14:18 |
| xjuan | but I am pretty sure GNOME will sponsor me | 14:18 |
| tristan | yeah I think sor | 14:18 |
| * tristan has to run, after 11pm here... | 14:18 | |
| * tristan will literally run :) | 14:18 | |
| xjuan | :) | 14:18 |
| xjuan | ok see you later! | 14:19 |
| *** tristan has quit IRC | 14:21 | |
| *** persia has joined #buildstream | 14:22 | |
| *** tristan has joined #buildstream | 14:48 | |
| jonathanmaw | hrm, looks like I'm going to need a bigger HDD to work on buildstream. I've got 145G, and 98G is being used by ~/.cache/buildstream | 14:52 |
| ironfoot | or a script to clean the cache in a clever way? | 14:55 |
| *** jude has quit IRC | 15:15 | |
| *** jude has joined #buildstream | 15:38 | |
| gitlab-br-bot | buildstream: merge request (jonathan/enhance-script-element->master: Jonathan/enhance script element) #22 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/22 | 15:49 |
| jonathanmaw | tristan: ^ | 15:49 |
| jonathanmaw | that ought to be closer to your expectations. | 15:50 |
| jonathanmaw | and of course I forgot to run setup.py test on it beforehand... | 15:51 |
| gitlab-br-bot | buildstream: merge request (jonathan/enhance-script-element->master: Jonathan/enhance script element) #22 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/22 | 15:55 |
| jonathanmaw | much better :) | 15:56 |
| *** jonathanmaw has quit IRC | 16:02 | |
| *** jude has quit IRC | 17:03 | |
| *** jude has joined #buildstream | 17:17 | |
| *** jude has quit IRC | 17:24 | |
| *** tristan has quit IRC | 20:12 | |
| *** xjuan has quit IRC | 20:44 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!