IRC logs for #buildstream for Tuesday, 2020-01-21

*** traveltissues has joined #buildstream08:37
*** phildawson has joined #buildstream08:40
*** traveltissues has quit IRC09:11
*** traveltissues has joined #buildstream09:12
gitlab-br-botjuergbi opened MR !1807 (juerg/buildbox-run-bind-mount->master: _sandboxbuildboxrun.py: Support host-files) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/180709:28
*** tme5 has joined #buildstream09:32
gitlab-br-bottmewett opened MR !1808 (tmewett/git-source->master: Improvements to _GitSourceBase and _GitMirror) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/180809:47
*** phildawson has quit IRC10:02
*** phildawson has joined #buildstream10:03
gitlab-br-botBenjaminSchubert approved MR !1807 (juerg/buildbox-run-bind-mount->master: _sandboxbuildboxrun.py: Support host-files) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/180710:05
*** jonathanmaw has joined #buildstream10:17
tme5benschubert, thanks for your comments, I've replied10:46
coldtomhi, if anyone gets time could i get a review (and hopefully a merge) on !1806 please?10:48
gitlab-br-botMR !1806: Stop plugin tests using private API https://gitlab.com/BuildStream/buildstream/merge_requests/180610:48
benschuberttme5: do you know a vway we could avoid doing a 'describe' instead of a 'rev-parse' there? describe is 20 times slower at least, and becomes worse with bigger repos :/10:53
benschubertif not, that's fine we can keep it like that until it becomes a more important problem, we are still sub second with 10k commits10:54
tme5oh really? i didn't know that10:55
benschuberttme5: for the workspace case, before git 2.0, you would not be able to push anything until you would do 'git pull --depths=${bigger_than_your_repo_history}' which can be unsettling for people not knowing git that well. I don't know whether we should take that in consideration there or not. git < 2.0 means all of RHEL 7 (would need to check for RHEL8)10:56
tme5it's just with ref-format: 'git-describe' describe has to be called anyway, so i thought this was an optimisation on the whole10:57
benschuberttme5: on the other hand it's only in 'track', which is ok-ish. But it's main process, so if you end up cloning the linux kernel, systemd and such, might be a hit10:58
benschubertMight be good testing on a big (public) repo :)10:58
benschuberttme5: on a big-ish repo (a few hundred megs), on my laptop under WSL: 'git rev-parse' takes 0.016s, 'git describe' takes 1.6s10:59
tme5but this is still a problem though, right? when ref-format is changed?11:02
benschubertit's definitely not idea11:03
benschubert*ideal11:03
benschubertbut not such of a big deal, so we could get it in like that and potimize later. But if we can know which one we need before running the command, I'd definitely try to optimize :)11:03
tme5do you have any idea how long it takes to start and finish a subprocess call from python?11:05
benschubertbased on a quick check doing: import time;import subprocess; def t(): s = time.time(); subprocess.check_call(["echo"]), print(time.time() - s), it's roughly 0.002s per call11:08
benschubert(not a real benchmark, really just a hack)11:08
tme5faster than for some reason i thought it would be11:09
benschubertpython is not that bad :)11:11
tpollardhaha11:12
tme5benschubert, w.r.t workspaces, i'm not sure I understand, are you saying if the workspace is opened without the source ever having done a full fetch, you will be unable to immediately push on old versions of Git?11:17
benschuberttme5: correct, and that might confuse most people :) I don't think we should cater for that, but might be worth checking with others before putting this change in, since it is a breaking change :)11:22
*** cs-shadow has joined #buildstream11:31
tme5it makes me wonder whether tracking will work either when a full fetch hasn't happened11:40
tme5i could just full-fetch before tracking and opening workspaces11:41
tme5but then i wonder whether the extra complexity is worth it, for optimising such a narrow case11:42
tme5actually i suppose it's still very useful if you're just using a buildstream project and not developing it, since you'll never track or open workspaces11:48
benschubertOr at least you won't be doing it for most elements :)11:49
*** santi has joined #buildstream11:51
gitlab-br-bottpollard closed issue #1151 (`bst shell --use-buildtree ask` uses `--pull` inconsistently) on buildstream https://gitlab.com/BuildStream/buildstream/issues/115112:11
gitlab-br-bottpollard merged MR !1767 (tpollard/shellbuildtree->master: _frontend/cli.py: Make show() --use-buildtree respect pull semantics) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/176712:11
*** phildawson has quit IRC12:12
benschuberttme5: for the git version and problems with git <2.0, let's not care about it and fix it when someone complains otherwise? Might be simpler and would enable a much faster experience for users12:16
tpollardthink about the transition of git/bzr/tar/autotools into experimental seems problematic to me12:41
tpollardadding to the mix that workspaces are technically source plugin now, but still core, but then require external input12:42
tpollard& source plugins being required in other core tests (such as cachekey for git/bzr), and what we want to classify doc tests as12:45
tpollardI like you idea of '@pytest.mark.plugins' benschubert, but I'm just worried everything could get a bit messy12:49
coldtommaybe core tests could minimise the dependency on external plugins, by either using ones to be left in core or creating some minimal plugin for testing12:51
coldtomi don't see a way around docs using external plugins if they want to be anything like real example projects12:52
*** narispo has quit IRC12:55
tpollardI agree on the docs test12:56
tpollardeven if we went back to considering a dedicated source cache for the docs12:57
*** phildawson has joined #buildstream13:00
*** phildawson has quit IRC13:24
benschuberttpollard: For workspace tests, we could use 'local' sources. For cache-key, we could use them with plugins installed13:40
benschuberttpollard: any specific concerns around the 'mark.plugins' getting messy?13:40
*** phildawson has joined #buildstream13:40
*** phildawson has quit IRC14:26
*** phildawson has joined #buildstream14:46
*** bochecha has joined #buildstream14:54
*** bochecha_ has joined #buildstream15:29
*** bochecha has quit IRC15:30
tpollardbenschubert: above what I mentioned above... I'm looking at moving pip source. Most of it is fine, but the pip element integration tests have a particular test that also requires the source plugin16:28
*** phildawson has quit IRC16:28
tpollardwhich would work with the 'mark.plugins' approach, but it's just another example of where they overlap16:32
*** traveltissues has quit IRC16:34
tpollardmost of it's fine being the extraction side https://gitlab.com/BuildStream/bst-plugins-experimental/merge_requests/7416:37
coldtomtpollard: should the pip element not be moved into bst-plugins-experimental anyway?16:44
tpollardyep16:44
tpollardwas hoping that it could be done separately though16:45
tpollardbut pip is a special case I guess16:46
benschuberttpollard: or move first the element? That should work :)17:10
tpollardyep!17:14
benschubertI'll send a ML post around the mark.plugins whenever I get time to look at the ML17:14
tpollardI'm glad pip is our only package manager in core17:15
tpollardbenschubert: thanks!17:15
*** santi has quit IRC17:25
*** tme5 has quit IRC17:28
*** santi has joined #buildstream17:47
*** jonathanmaw has quit IRC18:04
*** santi has quit IRC20:15
*** santi has joined #buildstream20:15
*** santi has quit IRC20:33
*** us has joined #buildstream20:34
*** us has left #buildstream20:34
*** santi has joined #buildstream23:41
*** santi has quit IRC23:45

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!