| *** tristan has joined #buildstream | 07:20 | |
| *** ChanServ sets mode: +o tristan | 07:29 | |
| *** Chris has joined #buildstream | 08:19 | |
| *** jonathanmaw has joined #buildstream | 08:27 | |
| tristan | jonathanmaw, ah perfect timing... I was just looking at trying to complete the bzr work to get it behind us... | 08:30 |
|---|---|---|
| tristan | jonathanmaw, and I'm unclear about why the 'ref' needs to be specified, why is that and what would I put there if I wanted track to give me, say, the "latest trunk" ? | 08:30 |
| tristan | I'm using emacs as a test, e.g.: http://bzr.savannah.gnu.org/r/emacs/ | 08:31 |
| jonathanmaw | tristan: I made ref mandatory because, AIUI having the code change from under you without warning is a headache. To find the latest ref, I'd set up the repo URL and branch name (put "trunk" if none in particular), and do `bst track <element>` | 08:32 |
| tristan | jonathanmaw, right, having code change without warning is unacceptable, ref should specify exactly what it is; and I think I'm comfortable if `track` is a mandatory, less specific component of the full ref | 08:34 |
| tristan | jonathanmaw, so I'm trying with specifying `trunk`, it's doing something... | 08:34 |
| tristan | I'm still not sure I understand why it must be specified... though | 08:35 |
| tristan | Are you saying that if one user specifies trunk/trunk on monday... and then does bst track | 08:35 |
| tristan | Another user which specifies trunk/trunk on friday... and then runs bst track... | 08:36 |
| tristan | And then both users later run bst track at exactly the same time two weeks later... they may obtain different results ?? | 08:36 |
| tristan | that sounds quite undesirable | 08:37 |
| jonathanmaw | tristan: I'm not sure why running bst track at the same time would give different results | 08:37 |
| tristan | jonathanmaw, well... that's exactly it, I dont understand why one must have something specified in 'ref' at all, and why it would induce sources changing without warning | 08:38 |
| tristan | so I am making a wild guess :) | 08:38 |
| tristan | trying to understand | 08:38 |
| jonathanmaw | ref here is a specific revision number. AIUI, without that, bzr would always give you the latest revision in a branch | 08:39 |
| tristan | Yes | 08:39 |
| *** ssam2 has joined #buildstream | 08:40 | |
| tristan | jonathanmaw, note that without a 'ref', buildstream will refuse to build | 08:40 |
| tristan | jonathanmaw, but a user is allowed to start off by only specifying 'track', and then run `bst track` before running `bst build` | 08:40 |
| tristan | it's of course highly recommended that the user keep a committed `ref` | 08:40 |
| jonathanmaw | tristan: ok. Is that a problem with how the bzr source is currently implemented? | 08:41 |
| tristan | jonathanmaw, Ok please search the text "Definitions of url, ref and track properties in a Source configuration", at: https://gitlab.com/BuildStream/buildstream/issues/10 | 08:41 |
| tristan | I think that is the best place I've explained it so far | 08:41 |
| * tristan does a little copy paste from there: | 08:41 | |
| tristan | A Project can be fetched and built if no track was ever specified for one or more Sources | 08:42 |
| tristan | A project cannot be built if there is no ref specified for one or more Sources | 08:42 |
| tristan | A source will have a ref if it was successfully tracked | 08:42 |
| tristan | A source which lacks a track configuration, cannot be tracked, but may be built if there is already a ref | 08:42 |
| jonathanmaw | tristan: so the problem is that bzr source has made track mandatory? | 08:42 |
| tristan | I'm more concerned with having 'ref' mandatory | 08:43 |
| tristan | it should not be mandatory to specify ref, if your intention is to have buildstream resolve ref from a specified track attribute | 08:44 |
| jonathanmaw | ok, so ref is mandatory when building, but shouldn't be mandatory in general? | 08:44 |
| tristan | jonathanmaw, this API implicitly tells the user that specifying something in 'ref' will have an effect on the outcome of `bst track` | 08:45 |
| tristan | which is absolutely should not, hence my confused `wild guess` above | 08:45 |
| tristan | Right | 08:45 |
| jonathanmaw | ok | 08:45 |
| tristan | Ideally, track is not mandatory for fetch + build, but only for `bst track` | 08:45 |
| tristan | so a resolved ref could be `trunk/<major>.<minor>.<micro>` (if the branch name for bzr absolutely needs to be specified for bzr interactions) | 08:46 |
| tristan | Alright, I guess I wont resolve this easily today | 08:46 |
| tristan | sorry I did not communicate this better | 08:47 |
| jonathanmaw | I see. | 08:47 |
| tristan | jonathanmaw, perhaps it would be good in the long term if I spent a bit more time enhancing https://buildstream.gitlab.io/buildstream/buildstream.source.html#module-buildstream.source | 08:47 |
| tristan | I should probably put a forward there, with much of the information found in issue 10 | 08:48 |
| tristan | to help implementors in general | 08:48 |
| jonathanmaw | ok. Once I've gotten my other work out of the way, I'll be able to come back to buildstream and redo the bzr source. I think it'll be at least a couple of days, unfortunately :/ | 08:49 |
| tristan | jonathanmaw, I'm not in a huge hurry to be honest for the bzr thing in particular; it's a hard requirement for a reliable migration path away from flatpak-builder | 08:51 |
| tristan | Also, I highly doubt this semantic change means "redo the bzr source" :) | 08:51 |
| tristan | I'm guessing you have a much better understanding of bzr than I do at this stage, and it's just a bit of an api change | 08:51 |
| jonathanmaw | tristan: a change to the source, yep. | 08:52 |
| tristan | great, I'll just put some comments in the issue for now | 08:53 |
| jonathanmaw | Of interest is `bzr help revisionspec`, there's a whole bunch of ways to specify a revision other than revision number. Though I'm not sure if their "branch:" specifier would actually help us, because it seems to be used solely to refer to the latest revision on a branch :/ | 08:53 |
| tristan | I think what you have done is functional (but emacs was perhaps a bad choice to test with, it's still mirroring trunk and it's _HUGE_ :)) | 08:56 |
| tristan | The important part is being able to track something specific | 08:56 |
| tristan | jonathanmaw, Note that 'ref' need not be a string, too; it's perfectly acceptable if ref is a dict | 08:57 |
| tristan | in the case you may need some more flexibility in addressing a perfectly exact revision, no need to cram it all into a string | 08:57 |
| tristan | jonathanmaw, anyway, interestingly `bst track` failed when specifying track:trunk, ref:trunk, although it was close to succeeding: https://bpaste.net/show/cc788e9e41a1 | 09:13 |
| tristan | failed on the rename | 09:13 |
| tristan | anyway, take your time | 09:13 |
| tristan | ah looks like the rename did not take the self.tmpdir() into account | 09:14 |
| tristan | anyway | 09:14 |
| *** Chris has quit IRC | 10:13 | |
| *** Chris has joined #buildstream | 10:29 | |
| * tristan just pushed a series of commits which I think vastly improve the user facing documentation fwiw | 10:34 | |
| tristan | See the new https://buildstream.gitlab.io/buildstream/ | 10:34 |
| tristan | Some of this (project configuration and user configuration), was just moved around a bit, but is now more discoverable and comprehensive (these sections used to be hiding in the Project and Context docs sections) | 10:35 |
| tristan | Also, a nifty new sphinx plugin seems to have surfaced since... about a month ago, and now we have auto-generation of docs for invoking buildstream (based on the doc strings and click decorators in the frontend main.py) | 10:36 |
| tristan | this will be quite the same as the man pages, but still nice to have in the docs | 10:37 |
| *** tristan has quit IRC | 12:39 | |
| *** tristan has joined #buildstream | 12:55 | |
| *** ChanServ sets mode: +o tristan | 12:58 | |
| *** jonathanmaw has quit IRC | 16:33 | |
| *** ssam2 has quit IRC | 16:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!