| *** hasebastian has joined #buildstream | 03:35 | |
| *** tristan has quit IRC | 03:38 | |
| *** tristan has joined #buildstream | 04:24 | |
| *** ChanServ sets mode: +o tristan | 04:24 | |
| tristan | Is it possible for a subproject to be overridden more than once in the ancestry ? | 05:59 |
|---|---|---|
| tristan | Or should it ? | 05:59 |
| tristan | Lets say project overrides subproject's junction to subsubproject with a different definition of subsubproject, which in turn has a subsubsubproject... and then project overrides that subsubsubproject in the same junction | 06:02 |
| tristan | hmm | 06:02 |
| juergbi | tristan: hm, you override junctions, not subprojects | 06:02 |
| juergbi | once a junction is overridden, the original one is irrelevant | 06:02 |
| tristan | juergbi, that is exactly what is untrue | 06:05 |
| tristan | juergbi, because duplicates and internal are project <--> junction relationships which are supposed to be preserved regardless of overrides | 06:06 |
| tristan | So I need to preserve what the original parents were at the time of override | 06:06 |
| juergbi | we need to formulate this more precisely | 06:07 |
| tristan | And I need to consider every plausible parent (not only the active parent) when constructing paths to search for duplicates | 06:07 |
| juergbi | i.e. distinguish between a junction name and a junction config | 06:07 |
| juergbi | or contents, whatever we call it | 06:07 |
| tristan | A junction config never enters into any equation | 06:07 |
| juergbi | junction config/contents are replaced when overridden | 06:07 |
| juergbi | only the junction name is still relevant | 06:07 |
| juergbi | and internal is about project to junction name | 06:08 |
| tristan | juergbi, https://bpa.st/7FKA | 06:11 |
| tristan | juergbi, I'm not sure if I've formulated it exactly correctly but maybe you can get what I'm getting at in that paste ? | 06:11 |
| tristan | Maybe my example needs one extra level of depth to be exactly realistic | 06:13 |
| tristan | subsubsubsubsubproject.bst could be overridden by subsubsubproject.bst's junction to subsubsubsubproject.bst | 06:14 |
| tristan | And the toplevel can *also* override subsubsubsubsubproject.bst directly from the toplevel | 06:14 |
| tristan | Two questions stand: (A) Which override wins ? (answer should be the toplevel, but I think my code has a bug there)... (B) Are both junctioning projects allowed to specify duplicate/internal for that same project, and should they *both* be taken into consideration ? | 06:15 |
| juergbi | ah, that's definitely an interesting aspect | 06:19 |
| juergbi | intuitively I'd be tempted to not allow overriding junctions via a path where the parent was already overridden | 06:19 |
| juergbi | i.e., require those overrides to be configured for the overriding, not the overridden path | 06:20 |
| juergbi | i.e., in your paste I'd forbid the second override line | 06:21 |
| juergbi | and require it to be specified as override in localsubsubsubproject.bst | 06:21 |
| juergbi | I haven't thought through this aspect, though, I might be missing something | 06:21 |
| tristan | I think it must be supported, not denied | 06:23 |
| tristan | Although your idea of denying it did immediately spring to mind | 06:23 |
| tristan | Rationale is mostly that, I should be able to freely override things in my subproject hierarchy without needing to fork things | 06:24 |
| tristan | So I should be able to override my subproject middleware with a different specialized/optimized middleware, which in turn also overrides some bsb or kernel or smth | 06:25 |
| tristan | But from my toplevel project, I should *also* be able to override that kernel | 06:25 |
| tristan | without forking the middleware | 06:25 |
| juergbi | tristan: I'm not saying to deny nested overrides in general | 06:26 |
| tristan | I mean, real world plausible usecases aside, the whole reason for supporting fullpaths in the keys (and values) of the overrides dictionary is to have this freedom to not force forking where it's not strictly needed | 06:26 |
| juergbi | only deny those where the parent (or generally, an ancestor) is already overridden | 06:27 |
| juergbi | and then you should still be able to override those via a non-overridden path without having to fork | 06:27 |
| tristan | Yes, but if I have a hierarchy where I override deeply nested things, it stands to reason that a project might want to also include me as a junction, and also have the freedom to override the things I override | 06:27 |
| tristan | In that top-toplevel view, I want to say override this shallow thing (which may have overridden a deeper thing), and also override that deep-deep-deep thing inside | 06:28 |
| juergbi | right, that's starting to get complex | 06:28 |
| tristan | Well, it's complex once | 06:28 |
| tristan | projects can stack hundreds of layers high | 06:29 |
| tristan | addressing a few layers vs hundreds has the same complexity (implementation-wise) | 06:29 |
| juergbi | sure, I meant to think about :) | 06:30 |
| tristan | Yes :) | 06:30 |
| tristan | So I came to IRC to share the load :) | 06:30 |
| tristan | So for implementing the overrides correctly, I am cooking up a test case and it's easy enough to solve | 06:30 |
| tristan | Instead of searching the closest parent for an override, I need to collect all overrides in the ancestry and choose the highest level one | 06:31 |
| tristan | That's the easy part | 06:31 |
| juergbi | I fear that it can get very confusing to the user to see which overrides are actually in place | 06:32 |
| tristan | For the duplicates/internal markers, I need to record *all* overrides in the walk, and say "The original parent, and all unchosen parents in the ancestry walk, are considered *alternative parents*" | 06:32 |
| tristan | Then, when I go ahead and check for duplicates/internal markers, I need to search every alternative parent for override markers | 06:32 |
| juergbi | when it gets complex to implement it often also gets complex for users to fully understand | 06:33 |
| tristan | for it's specific pathing to that project | 06:33 |
| tristan | For the user, absolute paths will always be displayed in the UI | 06:33 |
| tristan | And if there is a junction conflict error, we list every instance of projects, and every duplicate marking, including a lot of context | 06:34 |
| tristan | juergbi, currently I have this: https://bpa.st/ZRTA | 06:35 |
| tristan | but it could use a bit of polish | 06:35 |
| tristan | juergbi, the (duplicated from 'project-name', loaded via 'full-junction-path') is in a loop | 06:35 |
| tristan | Showing every place a project was duplicated from | 06:35 |
| juergbi | such provenance in error messages will definitely be very useful | 06:36 |
| tristan | For the provenances shown, we should ensure that they always contain the full junction paths | 06:36 |
| juergbi | however, I'm also worried about the case without errors | 06:37 |
| tristan | Should we also have something in the summary at the beginning of a build ? | 06:37 |
| juergbi | maybe allow showing the whole effective subproject structure of a pipeline | 06:38 |
| tristan | The summary is currently *horribly broken* | 06:38 |
| tristan | it gets printed for every project we load, showing a lot of redundant information, revealing that we don't care at all about logging properly | 06:38 |
| tristan | It's very embarrassing anyway | 06:39 |
| tristan | From the same test run, I have the following full stderr: https://bpa.st/NA7Q | 06:41 |
| tristan | juergbi, Anyway, I would prefer to change the summary separately, I would suggest that we revert to only printing a single summary, and modify it to have a loop for all loaded projects | 06:44 |
| juergbi | what? that's a single bst invocation? | 06:44 |
| tristan | Yes | 06:44 |
| juergbi | that's horrible | 06:45 |
| tristan | It appears as if at some point, the loading of a project became some kind of callback that causes the frontend to print a summary | 06:45 |
| juergbi | seems that way | 06:45 |
| tristan | Yes, it's disgusting, I can't believe we landed it to do that | 06:45 |
| tristan | Anyway, I would revert that but separately from the branch, give it a session of loving | 06:46 |
| juergbi | real testing probably mostly without junctions and in test cases you normally don't notice this | 06:46 |
| tristan | Show the active options for each project, and show the provenance of their junctions, and show any duplicate/override status, for each project loaded | 06:46 |
| juergbi | yes, I think that might be really helpful | 06:47 |
| juergbi | not sure whether provenance should be opt-in. might be too verbose | 06:47 |
| tristan | In test cases you notice because, you are implementing a test case and probably asserting expected provenance of errors etc | 06:47 |
| tristan | Or seeing the test case fail | 06:47 |
| tristan | Well | 06:47 |
| tristan | Maybe we have a lot of tests which dont exercise junctions :) | 06:48 |
| tristan | We only exercise them where we implement/test them (which makes sense) | 06:48 |
| tristan | juergbi, I think provenance of each loaded project is important, and goes hand in hand with it's junction on the same line | 06:48 |
| tristan | It's not all that much, unless you really do have hundreds of projects in depth | 06:49 |
| tristan | But then you will have a huge summary anyway if you want to show them | 06:49 |
| juergbi | fair enough | 06:49 |
| juergbi | we also normally show the status of every element in the pipeline, right? | 06:49 |
| tristan | In this sample, we don't get that far | 06:50 |
| juergbi | the number of junctions/subprojects should typically be way less than that | 06:50 |
| tristan | because this is a test of a load error | 06:50 |
| juergbi | right | 06:50 |
| juergbi | so as long as it's ok to print a line for every element, we sure can print a line for every subproject | 06:50 |
| juergbi | *surely | 06:50 |
| tristan | Yes, definitely | 06:50 |
| tristan | I would have the pipeline completely at the end of the summary as originally implemented | 06:51 |
| tristan | So it would flow { BuildStream version information, Invocation information and settings, Loaded projects (junctions), Pipeline of elements } | 06:52 |
| tristan | I think while being clear about all of this (showing duplicate/internal statuses as well), yes it may be complex for large projects but good enough for users to understand | 06:53 |
| *** benschubert has joined #buildstream | 07:17 | |
| benschubert | tristan: juergbi : I had an initial quick look yesterday around using threads for the jobs: | 07:22 |
| benschubert | - We can't do 'fine grained' async, as in we must run the entire job in a separate thread for now, as doing differently would require huge changes in the Messenger. | 07:22 |
| benschubert | - Apart from signal handling (I can't handle pause/terminate for now), it seems to work on a manual build, still need to look at the tests | 07:22 |
| juergbi | sounds like a good start :) | 07:23 |
| juergbi | I assume proper signal handling is not impossible even though it may be non-trivial | 07:24 |
| juergbi | so I think it's really a better direction to explore than (extensive) pickling | 07:24 |
| benschubert | For proper signal handling: | 07:29 |
| benschubert | - we have a helper for all subprocesses spawned, we "just" need to call it from the main process instead of the threads | 07:29 |
| benschubert | - For the threads themselves, it's trickier: We can't 'terminate' anymore, but we can cancel the job, which would raise a CancelledException, which unless caught will kill the thread. So as long as it's not caught we should be fine. And for pausing, I'm thinking if there is a way we could forcefully keep the gil or something like this (otherwise well... ) | 07:29 |
| benschubert | and now the messenger needs to have thread-local variables | 07:29 |
| benschubert | but yeah seems promising | 07:30 |
| benschubert | the MR will be hard to make nice though | 07:30 |
| juergbi | Only the frontend in the main process might actually make this easier | 07:30 |
| juergbi | But that separation itself may not be trivial without fork | 07:31 |
| juergbi | Although, spawn might not be too bad for that when done at the right place | 07:32 |
| juergbi | (performance is still a question, though) | 07:32 |
| juergbi | With the separation we could send SIGTSTP from the frontend to the core. handle SIGTSTP in the core to suspend all subprocesses and then suspend the core process itself (all threads) | 07:34 |
| benschubert | yep, that would be the ideal solution | 07:34 |
| benschubert | and I'm not too concerned about performance there as long as it's the backend that has all the state, the spawn would be once | 07:34 |
| benschubert | We'll see what tristan can come up with on that one :) | 07:35 |
| juergbi | my performance comment was more about the separation of frontend and core into two processes in general | 07:35 |
| juergbi | i.e., the messaging performance bottleneck that we saw with the separation experiment | 07:35 |
| benschubert | ah true | 07:36 |
| juergbi | or did rate limiting also solve it when the two parts are separated? | 07:36 |
| benschubert | if we rate limit from the backend it might work? | 07:36 |
| juergbi | we just didn't need it anymore? | 07:36 |
| juergbi | it's possible | 07:36 |
| benschubert | not sure I get you? The rate limiting is here, but it only limits the number of time we refresh the screen | 07:38 |
| juergbi | ah, right | 07:39 |
| juergbi | I didn't remember where we rate limited | 07:39 |
| juergbi | also don't remember whether interactive shell still had some issues with separated frontend | 07:40 |
| juergbi | it's a somewhat tricky aspect | 07:40 |
| juergbi | or at least might be | 07:40 |
| tristan | Hmmm | 07:41 |
| * tristan gets back from sandwich | 07:41 | |
| tristan | benschubert, I think that most of what we currently manually do for subprocesses from the main process can also be done at API entrypoints from plugins running in the main process | 07:42 |
| tristan | benschubert, i.e. the context managers in _signals.py | 07:42 |
| tristan | It does sound like you've made some good progress though :) | 07:42 |
| benschubert | yeah it's ugly though :'D | 07:43 |
| tristan | For SIGTERM, could we not handle it from the main process and send SIGTERM to child processes ? | 07:43 |
| tristan | i.e. whenever the plugin calls something that creates a child process, we certainly have the right to know about it | 07:43 |
| benschubert | tristan: child processes would be buildbox-run/casd/git/ssh etc, we do have them pauseable and that should not cause troubles | 07:43 |
| benschubert | (I have a bug in what I did that I need to fix in order for it to really work) | 07:44 |
| benschubert | but yeah that is fine | 07:44 |
| benschubert | what's more complex is for SIGTSTP, which means we want to pause the threads | 07:44 |
| benschubert | which we might force by keeping the GIL | 07:44 |
| benschubert | but that's less than ideal | 07:44 |
| tristan | Hmmm | 07:45 |
| tristan | benschubert, I don't think it's important to pause the threads | 07:45 |
| benschubert | oh that simplifies a ton of things then :) If we are happy only pausing the sub processes then it is definitely doable | 07:46 |
| tristan | This entire approach of running client code in the main process is hinged on the assumption that long standing work never happens in the main process | 07:46 |
| benschubert | true | 07:46 |
| benschubert | let's hope no plugin will ever want to run a multiprocess in their plugin, otherwise it will be funky | 07:47 |
| tristan | If that's true, the time from which a plugin should be paused until it reaches a function that would otherwise launch something and block should be negligible | 07:47 |
| benschubert | true | 07:47 |
| tristan | We'll have to ensure that we block plugins from launching anything if they should be paused, of course | 07:47 |
| benschubert | though if you _start_ a subprocess after being paused, the subprocess will not receive the message | 07:47 |
| benschubert | so we'd need a barrier | 07:47 |
| benschubert | ah yep | 07:47 |
| benschubert | yeah we can easily add a barrier somewhere | 07:48 |
| benschubert | ok ! I'll go back to it tonight probably and will see how far I can go | 07:48 |
| tristan | Yeah but code which runs a subprocess in a plugin which does not pass though BuildStream API to do so, is just invalid plugin code | 07:48 |
| tristan | Then of course we get back into the can of worms which says "Hey, my plugin is written in Python, So I should be allowed to have python library dependencies... Right ?!?!?" | 07:48 |
| * tristan doesnt like this argument | 07:49 | |
| tristan | If people are allowed to have third party python library dependencies, then we don't retain control over what plugins do, and they might launch unexpected subprocesses | 07:49 |
| tristan | along with all the other problems third party library dependencies bring in | 07:49 |
| benschubert | yep | 07:49 |
| benschubert | which is acceptable if people understand what that implies | 07:50 |
| tristan | benschubert, fwiw, we had an interesting conversation before you arrived... https://irclogs.baserock.org/buildstream/%23buildstream.2020-06-17.log.html#t2020-06-17T05:59:51 | 07:54 |
| tristan | I think I have it under control... but e.g. consider: https://bpa.st/7FKA | 07:54 |
| tristan | benschubert, this is regarding overriding subsubsubsubsubsubsubprojects inside subsubsubsubprojects, which already did override that subsubsubsubsubsubsubsubproject | 07:55 |
| benschubert | oh gosh | 07:55 |
| tristan | who wins, and how to determine internal/duplicates regarding those, which references to count, etc | 07:56 |
| tristan | Yeah :) | 07:56 |
| tristan | Thought you'd enjoy that :) | 07:56 |
| benschubert | > i.e., require those overrides to be configured for the overriding, not the overridden path | 07:57 |
| benschubert | I think that is the most important point, junctions overrides should be applied recursively, so you'd be overriding the override instead of the junction directly | 07:57 |
| benschubert | for the rest I'll have to read it with a bit more thoroughness to understand the output of it :) | 07:58 |
| tristan | yes you'd be overriding the overridden branch, but the tricky thing is that you can be overriding something which was already overridden by an intermediate project | 08:05 |
| tristan | on your way to reaching that project | 08:05 |
| tristan | So when you search your ancestry for a junction which overrides you, you cannot stop at the nearest ancestor, there can be a greater grandparent which also overrides you | 08:06 |
| tristan | Which also means that there can be multiple active override points which declare you to be 'internal' or 'duplicate' | 08:07 |
| tristan | In fact, this situation can even arise without the double declaration described in https://bpa.st/7FKA | 08:07 |
| benschubert | yep, which means the loader code will take a hit and be quite complex :/ | 08:09 |
| tristan | Well | 08:09 |
| tristan | It's actually not that much | 08:09 |
| tristan | benschubert, https://gitlab.com/BuildStream/buildstream/-/blob/tristan/junction-jungle/src/buildstream/_loader/loader.py#L596 | 08:10 |
| tristan | benschubert, That code has a bug as it currently is satisfied by the nearest ancestor | 08:11 |
| benschubert | tristan: and we only do that once per junction correct? Not everytime we reach one of their elements | 08:11 |
| tristan | It needs to keep crawling the ancestry and find all override declarations, and use the highest level one | 08:11 |
| tristan | Once per junction yes | 08:11 |
| tristan | Only to resolve which junction to ultimately load | 08:11 |
| benschubert | ah right, ok :) | 08:12 |
| tristan | The other half is yet unimplemented, which is to preserve the relationship of alternative parents | 08:12 |
| tristan | So that I can preserve the "duplicate" relationships of projects and junctions, when those "duplicate" junctions get overridden by some ancestor | 08:13 |
| tristan | That has to be a list, not a single duplicate | 08:13 |
| tristan | When asserting duplicates, the more overrides you have, the more expensive that operation becomes indeed | 08:13 |
| tristan | You need to collect duplicate-ness for any alternative parent (or 'overridden parent') | 08:13 |
| benschubert | but that's once per junction so I'd expect this to be pretty cheap right? | 08:15 |
| benschubert | I mean compared to the rest of the loading | 08:15 |
| tristan | So the resolution of "is this junction duplicated" needs to be done once per loaded instance of a given project | 08:16 |
| tristan | And the resolution of "is this junction duplicated" is then multiplied by the number of times that junction was overridden | 08:16 |
| tristan | AFAICS | 08:17 |
| tristan | I have been struggling to even get an algorithm which determines whether an overridden junction was duplicated working, but figuring out that I need to store the alternative parents is what lead me to realize this shortcoming and multi-override situation | 08:18 |
| tristan | The resolution of "is this junction duplicated" itself, requires a Loader.get_loader() walk from the project which declares duplicates, too | 08:18 |
| tristan | benschubert, https://gitlab.com/BuildStream/buildstream/-/blob/tristan/junction-jungle/src/buildstream/_project.py#L572 | 08:19 |
| benschubert | tristan: yeah, that seems unfortunate, I don't have a better idea though, not sure how I can help, unless you have more specifics :) | 08:37 |
| tristan | Let me get working code out and revisit then | 08:43 |
| tristan | I'm personally very happy with the support for links | 08:44 |
| tristan | And I don't have better ideas at this point to optimize, but maybe there are caching possibilities I've missed | 08:44 |
| tristan | I also don't really expect this to be a hot codepath realistically | 08:44 |
| *** santi has joined #buildstream | 08:48 | |
| benschubert | yeah definitely | 08:49 |
| benschubert | let's not optimize too early | 08:49 |
| tristan | First issue of overrides now has a test case and fixed... now on to preserving the relationship of duplicates for any overridden junctions | 09:01 |
| *** hasebastian has quit IRC | 09:42 | |
| *** tristan has quit IRC | 10:15 | |
| WSalmon | We manged to find one of these odd failure in CI, douglaswinship traveltissues benschubert | 10:41 |
| WSalmon | https://gitlab.com/BuildStream/buildstream/-/issues/1341#note_362785120 | 10:41 |
| WSalmon | benschubert, my current gues as to the above is that a plugin is returning something from get_unique_key that is then making the cache key calculation go pop, dose that seem sensible? | 11:12 |
| WSalmon | im guessing there is a bug in the plugin and a bug in bst were it is not parsing the values from get_unique_key safely | 11:13 |
| WSalmon | ? | 11:13 |
| WSalmon | it would be great if bst could at least say which plugins get_unique_key was causing the issue | 11:14 |
| douglaswinship | Agreed, that would be _really_ useful for debugging. | 11:18 |
| coldtom | flatpak_image or flatpak_repo | 11:19 |
| * coldtom hit this before | 11:19 | |
| douglaswinship | i think this one is a snap_image | 11:19 |
| douglaswinship | sidebar: is there not a 1.93.4 tag for bst-plugins-experimental yet? Are we treating the 1.93.3 tag as being compatible with 1.93.4? | 11:20 |
| douglaswinship | *compatible with bst 1.93.4 | 11:21 |
| douglaswinship | Back to the bug: I didn't look closely at the link. The one is clearly a flatpak thing, yes. I had the same issue on CI though, (the link that will posted in the comments). That's the one I think was a snap_image problem. | 11:23 |
| WSalmon | narrowing it down two two plugins should give you a good start, but see if you can use bst show to be sure | 11:25 |
| WSalmon | which one | 11:25 |
| WSalmon | it could be both | 11:25 |
| douglaswinship | I will :) just wrestling with venvs at the moment. | 11:25 |
| WSalmon | :) | 11:25 |
| douglaswinship | will DM you a question about the docker image | 11:25 |
| coldtom | it's flatpak_image | 11:26 |
| WSalmon | there worth mastering | 11:26 |
| *** hasebastian has joined #buildstream | 11:28 | |
| *** tristan has joined #buildstream | 11:44 | |
| *** ChanServ sets mode: +o tristan | 11:44 | |
| douglaswinship | Has anyone else had trouble with tab completion in 1.93.4? I had the same issue in 1.93.3. I get some python code crashing and throwing up a traceback any time I try to tab complete a bst command. | 11:51 |
| douglaswinship | "Cannot import name '__version__' from 'buildstream'" | 11:52 |
| tristan | Hmmm, I've been reproducing this in `tox -e venv /bin/bash` but wasn't sure to blame buildstream or tox setup | 11:59 |
| coldtom | I've had that issue too | 12:03 |
| douglaswinship | Pretty sure it's caused by "6ef6be52 Replace format-version with min-version" | 12:17 |
| tristan | should be easy to fix | 12:18 |
| douglaswinship | For me, the bug happens every time, after that commit. And never before that commit. | 12:18 |
| douglaswinship | Or looks like, anyway) | 12:18 |
| * tristan wonders which... douglaswinship or coldtom... will fix it first | 12:20 | |
| tristan | ready... set... | 12:20 |
| tristan | Go ! | 12:20 |
| douglaswinship | um.... I cheated. I've already started. | 12:21 |
| douglaswinship | sorry coldtom :) | 12:21 |
| douglaswinship | Okay, I don't really know enough to be confident yet, but src/buildsteam/_versions.py had two lines deleted: "BST_FORMAT_VERSION = 25" & "BST_FORMAT_VERSION_MIN = 18". That makes sense, if the whole commit was about removing the "BST_FORMAT_VERSION" variable from buildstream. But shouldn't they have been replaced with something relating to the "MIN_VERSION" variable? | 12:26 |
| WSalmon | that dose look a lot like stuff tristan did.. | 12:28 |
| tristan | douglaswinship, just not in the same commit, why, does autocompletion require knowledge of a min version or smth ? | 12:33 |
| tristan | douglaswinship, I'm thinking, either the import is unneeded, or it's changed location | 12:33 |
| douglaswinship | yeah, i'm guessing i was wrong about '_versions.py'. | 12:34 |
| douglaswinship | But either way, i can't investigate any further for now. I've got to prioritize some other things, and I don't think I know enough to figure this out on my own anyway. | 12:35 |
| tristan | Sweeeeeeeet | 12:44 |
| tristan | Overrides + Duplicate markings = Magic | 12:44 |
| tristan | douglaswinship, utils.py:get_bst_version() explains that __version__ is not resolved at bash complete time apparently | 12:48 |
| tristan | douglaswinship, I seem to have overlooked this when I wanted to make the default argument for `bst init` be the current version: https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_frontend/cli.py#L374 | 12:50 |
| tristan | Removing that function and perhaps defaulting to "2.0" or such could be a reasonable couple-line fix | 12:50 |
| douglaswinship | Seems to work! | 12:52 |
| douglaswinship | I assume you're suggesting that as a local fix? Not as something to actually merge into master? | 12:52 |
| tristan | I'm suggesting that as a fix for master yeah | 12:52 |
| douglaswinship | Ah, awesome. | 12:53 |
| tristan | It's not really immensely important that the default be the current version | 12:53 |
| tristan | Would have been a bit prettier | 12:53 |
| douglaswinship | Still, it's a shame to hard code a version number in, that people will have to remembe to update in future. | 12:53 |
| tristan | Well, its a function that has questionable value in the first place (`bst init`) | 12:54 |
| tristan | I expect most people who actually author projects will compose a project.conf | 12:54 |
| tristan | And maintaining a min-version is necessary | 12:54 |
| tristan | `min-version: 2.0` just means that you do not use any feature from BuildStream 2 that was introduced after 2.0 | 12:55 |
| tristan | douglaswinship, for the BuildStream side, we'll only really have to update it when BuildStream 3 comes out (unless people feel picky about that minute detail of a feature I guess) | 12:56 |
| tristan | BuildStream 3 I guess will ideally come out... never | 12:57 |
| *** toscalix has joined #buildstream | 14:25 | |
| *** toscalix has quit IRC | 15:40 | |
| *** toscalix has joined #buildstream | 15:42 | |
| *** hasebastian has quit IRC | 16:33 | |
| *** toscalix has quit IRC | 17:01 | |
| *** santi has quit IRC | 17:02 | |
| douglaswinship | Is anyone familiar with the virtual directory code? I was taking a look and trying to figure out what kind of inputs "descend" will accept. | 17:03 |
| douglaswinship | It looks like you're expected to do "foo.descend(['bar', 'baz'])" (separating out the components of the path). So is the path is a variable, you have to do "path.split(os.sep)" first. | 17:03 |
| douglaswinship | But I was wondering if you can do "foo.descend(['bar/baz']). (Without splitting the string). | 17:03 |
| douglaswinship | I took a look at the code in src/buildstream/storage/_filebaseddirectory.py, and it looks like it would actually accept 'bar/baz' as an input, but I don't think it would handle it properly. | 17:03 |
| douglaswinship | I think the code would jump from the foo directory, straight to the foo/bar/baz directory in a single step. You'd end up with a directory object representing the 'foo/bar/baz' folder, but it would incorrectly list 'foo' as the parent directory, and skip over the 'foo/bar' directory completely. | 17:03 |
| douglaswinship | Maybe there's a sanitizing step that i've overlooked? But if not, then I think there's a bug there. | 17:04 |
| *** douglaswinship has quit IRC | 17:28 | |
| *** bethw has quit IRC | 17:31 | |
| *** traveltissues has quit IRC | 17:31 | |
| *** robjh has quit IRC | 17:31 | |
| *** WSalmon has quit IRC | 17:32 | |
| *** valentind has quit IRC | 17:32 | |
| *** robjh has joined #buildstream | 17:33 | |
| *** bethw has joined #buildstream | 17:34 | |
| jjardon | some good words for buildstream here: https://github.com/winepak/winepak-sdk-images/issues/45 :) | 17:36 |
| *** valentind has joined #buildstream | 17:37 | |
| *** WSalmon has joined #buildstream | 17:37 | |
| *** xjuan has joined #buildstream | 18:19 | |
| *** xjuan has quit IRC | 23:00 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!