*** delli3 has quit IRC | 06:50 | |
*** delli3 has joined #buildstream | 06:50 | |
*** traveltissues has joined #buildstream | 08:35 | |
*** traveltissues has quit IRC | 08:38 | |
*** tiagogomes has joined #buildstream | 09:55 | |
*** phildawson_ has joined #buildstream | 10:07 | |
*** jonathanmaw has joined #buildstream | 10:27 | |
*** lachlan has joined #buildstream | 10:36 | |
*** lachlan has quit IRC | 10:47 | |
*** lachlan has joined #buildstream | 10:49 | |
*** lachlan has quit IRC | 10:51 | |
*** lachlan has joined #buildstream | 11:27 | |
*** lachlan has quit IRC | 11:30 | |
*** traveltissues has joined #buildstream | 11:42 | |
*** lachlan has joined #buildstream | 12:00 | |
*** lachlan has quit IRC | 12:55 | |
*** traveltissues has quit IRC | 12:56 | |
*** traveltissues has joined #buildstream | 13:41 | |
gitlab-br-bot | traveltissues opened (was WIP) MR !1761 (traveltissues/1216->master: mtime support) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1761 | 13:51 |
---|---|---|
*** traveltissues has quit IRC | 13:54 | |
*** traveltissues has joined #buildstream | 13:55 | |
tpollard | hmmm, can't manually instantiate traceback objects until 3.7 | 14:26 |
*** lachlan has joined #buildstream | 14:28 | |
tpollard | ^ that makes !1788 a bit trickier juergbi | 14:28 |
gitlab-br-bot | MR !1788: scheduler.py: Handle exceptions that are caught under the event loop https://gitlab.com/BuildStream/buildstream/merge_requests/1788 | 14:28 |
*** lachlan has quit IRC | 14:34 | |
*** lachlan has joined #buildstream | 14:34 | |
*** lachlan has quit IRC | 14:38 | |
juergbi | tpollard: we could just None for the tb | 14:39 |
juergbi | should probably prefix the message with something to make clear that it's from the asyncio exception handler | 14:40 |
juergbi | traceback.format_exception() seems to accept None as tb | 14:40 |
*** lachlan has joined #buildstream | 14:57 | |
*** lachlan has quit IRC | 15:11 | |
tpollard | yep it does, should be fine with we tell mypy to ignore that call to the excepthook | 15:11 |
tpollard | as it can't tell that we've overriden it globally with a method that doesn't type check the parameters | 15:11 |
*** lachlan has joined #buildstream | 15:16 | |
*** lachlan has quit IRC | 15:20 | |
douglaswinship | Huh, project.get_alias_uris() behaves strangely. | 15:26 |
douglaswinship | or rather, behaves strangely when there are no alias uris to return. | 15:26 |
douglaswinship | I'd have expected it to return an empty list | 15:26 |
douglaswinship | Instead it gives a list with "None" as the only element in the list. | 15:27 |
douglaswinship | so I had a loop that starts "for thing in project.get_alias_uris():" and I got some strange errors. | 15:30 |
*** lachlan has joined #buildstream | 15:30 | |
douglaswinship | I suppose the function isn't ever expected to be called with an invalid alias, so it's not supposed to come up. Still, seems odd. | 15:31 |
tpollard | I've not touched that area of the code, but on the face of it I agree that seems odd | 15:31 |
benschubert | can you open an issue or investigate a bit more? I agree it looks like a bug there | 15:32 |
douglaswinship | benschubert: this might sound silly, but i'm not confident enough to raise that sort of issue, especially on a project i'm not directly involved in. | 15:33 |
*** lachlan has quit IRC | 15:34 | |
douglaswinship | I'm still such a new/inexperienced programmer, and I keep imagining i'm blundering into things I shouldn't be using, or using them wrong. | 15:34 |
douglaswinship | so raising an issue would be kind of intimidating | 15:35 |
*** traveltissues has joined #buildstream | 15:36 | |
tlater[m] | Hm, someone seems to have snuck in a patch that doesn't respect tox formatting | 15:40 |
benschubert | Not silly at all, I understand and guess we are many who have come through this. And starting in a new project is always something challenging. | 15:44 |
benschubert | What I learned with time is that many project don't have enough bandwidth to check everything and when they get sufficientely large, it becomes hard to follow everything and find all those problems and that opening an issue to at least ask for clarification is always helpful, because it will in the worst case document the problem :) (I would recommend looking a bit in the issues first to ensure that there is not already | 15:44 |
benschubert | one) | 15:44 |
benschubert | For what I know around the issue there: https://gitlab.com/BuildStream/buildstream/blob/master/src/buildstream/_project.py#L431 is the culprit, and seems to be done on purpose. I would expect that many tests would fail if that was changed. | 15:44 |
benschubert | Maybe jonathanmaw would have more information around this? But it's a long time ago :'D | 15:44 |
benschubert | douglaswinship: (One approach I usually do though is I start with one issue on a project and see how people react there, and if it's welcome I continue ;), always depends on the project) | 15:44 |
douglaswinship | benschubert: good advice. I'll try and buck up the courage to do that, in future. | 15:47 |
benschubert | tlater[m]: I believe I'm done with !1739 if you have time to have a look at it :) I'm just re-running benchmarks and will unwip + send the ML post as soon as I have them done, TLDR: 1m30 to 15-17s for a 'bst show' on an internal project :D | 15:47 |
gitlab-br-bot | MR !1739: WIP: Optimize consistency and state handling https://gitlab.com/BuildStream/buildstream/merge_requests/1739 | 15:47 |
douglaswinship | for now, it seems like this has a good reason for being there. (or at least a good reason for us to change it now). | 15:48 |
benschubert | douglaswinship: gets easier every time and I personally have found very few communities not welcoming more help :D | 15:48 |
tlater[m] | benschubert: Well, you happen to catch me on some down time... | 15:48 |
douglaswinship | Now i know about it, i can just sanitize the outputs | 15:48 |
benschubert | tlater[m]: figured it out since you were there ;) | 15:49 |
benschubert | douglaswinship: are you working on a plugin? | 15:49 |
douglaswinship | no, a script, which i'll be posting soon and asking for advice on. | 15:50 |
benschubert | ok! | 15:50 |
cs-shadow | tlater[m]: is black complaning at the moment? | 15:50 |
*** lachlan has joined #buildstream | 15:50 | |
tlater[m] | cs-shadow: If I run tox -e format it reformats some files I didn't change | 15:50 |
tlater[m] | Though in retrospect, this is on a branch I rebased against another | 15:51 |
tlater[m] | So it might just be that that branch contains something unblack | 15:51 |
tlater[m] | It's been marked as non-WIP, so I assumed it was right, but that's no guarantee ;) | 15:51 |
benschubert | tlater[m]: I don't have a problem on my branch that I just rebased on master :) | 15:55 |
tlater[m] | Right, then nevermind me | 15:55 |
tlater[m] | Though that'll probably mean my CI will fail again :| | 15:55 |
benschubert | tlater[m]: also for 1739, does the 'breakage' seems fair to you? (In user-behavior, in the description) | 15:56 |
tlater[m] | benschubert: You mean the one in the NEWS entry? | 15:56 |
benschubert | no, https://gitlab.com/BuildStream/buildstream/merge_requests/1739#breaking-behaviors | 15:57 |
benschubert | (which I actually forgot to put in the NEWS) | 15:57 |
tlater[m] | Huh, it didn't even show me that | 15:58 |
tlater[m] | Let me read... | 15:59 |
benschubert | tlater[m]: just updated the NEWS so if you refresh that should be fine | 15:59 |
tlater[m] | benschubert: Mind adding a recommendation to use `bst source delete`, assuming we have that? | 16:01 |
benschubert | I'm not sure it's a good thing advertising before we have it :/ | 16:01 |
tlater[m] | If we don't, I think I'd rather not see this patch without a command to also do that. | 16:01 |
tlater[m] | Hmm | 16:01 |
tlater[m] | I'd just like to see that workflow documented properly, and I'm a little worried we forget if we don't do it now. | 16:02 |
tlater[m] | But the breakage itself seems fine. | 16:02 |
benschubert | the problem with 'source delete' is that sources would need implementing it no? | 16:03 |
cs-shadow | tlater[m]: sometimes that can also be because of a new black release. But it hasn't changed since 28 Oct | 16:03 |
tlater[m] | benschubert: Would they? Couldn't we just purge the specific entry from the cas? | 16:04 |
tlater[m] | Sources are in cas now, right? | 16:04 |
benschubert | they are both local and in cas | 16:05 |
tlater[m] | Hm, in either case, I'm really hestitant to introduce anything that forces users to manually blow up their cache after that one guadec. | 16:06 |
tlater[m] | It's not really acceptable workflow | 16:06 |
benschubert | and I wonder whether bst source delete $element seems right | 16:06 |
benschubert | I mean, it's only if they want to check again for the warning | 16:07 |
benschubert | and if they want to fix the warning, that also means modifying the source ref | 16:07 |
benschubert | so it will need to be re-imported | 16:07 |
benschubert | no? | 16:07 |
tlater[m] | Ah, and I suppose in that case it will show up anyway | 16:08 |
tlater[m] | benschubert: Right, in that case I think the news entry just needs to clarify that it's the same _exact_ source | 16:08 |
*** lachlan has quit IRC | 16:08 | |
benschubert | mmh actually the comment in the NEWS is wrong yep | 16:08 |
benschubert | ah shoot, it is dependent on 'get_unique_key' | 16:10 |
*** lachlan has joined #buildstream | 16:10 | |
benschubert | which might not be fine | 16:10 |
benschubert | even though the git plugin does it correctly for example | 16:11 |
coldtom | would there be interest in having this plugin in bst-plugins-experimental? It produces python wheels https://gitlab.com/celduin/burn-sdk/tree/coldtom/add-bgd/plugins/elements | 16:11 |
tlater[m] | benschubert: I think `get_unique_key` has to be guaranteed to actually be unique on the plugin end | 16:12 |
tlater[m] | Otherwise this is a bug on the plugin end | 16:12 |
persia | I think so. While some folk use buildstream to compose full systems, using it to produce packages in various formats seems like a sensible use case. | 16:12 |
tlater[m] | benschubert: In what sort of case do you expect that to be a problem, outside of broken plugins? | 16:13 |
benschubert | coldtom: what about making it more flexible and allowing source packages too? :) | 16:13 |
benschubert | tlater[m]: none | 16:14 |
benschubert | that I can think off | 16:14 |
tlater[m] | Maybe check with traveltissues that this doesn't break workspaces | 16:14 |
tlater[m] | Because I can't quite remember how those handle `get_unique_key` | 16:14 |
benschubert | tlater[m]: as far as the tests go, it doesn't | 16:14 |
tlater[m] | But outside of that, LGTM | 16:15 |
tlater[m] | I'll approve whenever you mark it as non-WIP | 16:15 |
benschubert | thanks! | 16:15 |
*** lachlan has quit IRC | 16:17 | |
cs-shadow | coldtom: yes, i think it will be great to have a generic `python_package` plugin, that can build both source distributions as well as binary wheels. | 16:17 |
cs-shadow | for later, I think we can also look into doing something for producing `manylinux` wheels as that's the only thing PyPI accepts for Linux | 16:17 |
coldtom | great! i'll work on making it more general and upstreaming it at some point then | 16:18 |
*** phildawson-ct has joined #buildstream | 16:19 | |
*** phildawson_ has quit IRC | 16:21 | |
*** lachlan has joined #buildstream | 16:32 | |
*** lachlan has quit IRC | 16:39 | |
tpollard | juergbi: can you check that you agree with 1788 now? I'd like to get it over the line without too much wrangling | 16:51 |
juergbi | ah, you needed special code in the handler after all? | 16:53 |
*** lachlan has joined #buildstream | 16:54 | |
juergbi | tpollard: commented with one possible simplification but overall makes sense to me | 16:58 |
juergbi | I don't know whether benschubert wants to take another look | 16:58 |
benschubert | I'm fine with the code now :) | 17:01 |
*** lachlan has quit IRC | 17:02 | |
*** lachlan has joined #buildstream | 17:05 | |
tpollard | juergbi: replied :) | 17:16 |
*** lachlan has quit IRC | 17:20 | |
tpollard | ta! | 17:21 |
* tpollard merges | 17:25 | |
gitlab-br-bot | tpollard closed issue #1245 (Install asyncio exception handler) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1245 | 17:25 |
gitlab-br-bot | tpollard merged MR !1788 (tpollard/loop_exception->master: scheduler.py: Handle exceptions that are caught under the event loop) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1788 | 17:25 |
benschubert | juergbi: if you have time would you mind having a look at !1739 see if I missed something? It's around state handling so... | 17:36 |
gitlab-br-bot | MR !1739: WIP: Optimize consistency and state handling https://gitlab.com/BuildStream/buildstream/merge_requests/1739 | 17:36 |
*** tpollard has quit IRC | 17:45 | |
*** lachlan has joined #buildstream | 17:46 | |
*** phildawson-ct has quit IRC | 17:49 | |
juergbi | benschubert: can't take a look right now. will probably have to wait until Monday | 17:51 |
benschubert | Sure, thanks a lot | 17:51 |
*** lachlan has quit IRC | 17:52 | |
gitlab-br-bot | BenjaminSchubert opened (was WIP) MR !1757 (bschubert/standardized-tests->master: introduce cross-repo standardized source tests) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1757 | 18:04 |
*** jonathanmaw has quit IRC | 18:42 | |
*** lachlan has joined #buildstream | 18:50 | |
*** tiagogomes has quit IRC | 18:52 | |
*** lachlan has quit IRC | 18:59 | |
*** lachlan has joined #buildstream | 19:04 | |
*** lachlan has quit IRC | 19:13 | |
*** lachlan has joined #buildstream | 20:00 | |
*** lachlan has quit IRC | 20:06 | |
*** lachlan has joined #buildstream | 20:15 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!