| *** kapil___ has joined #buildstream | 00:28 | |
| *** max has quit IRC | 00:31 | |
| *** lsfranco has joined #buildstream | 00:32 | |
| *** nimish has joined #buildstream | 01:46 | |
| *** tristan has joined #buildstream | 02:23 | |
| *** kapil___ has quit IRC | 02:47 | |
| *** nimish has quit IRC | 03:23 | |
| *** lsfranco has quit IRC | 05:28 | |
| *** abderrahim32 has quit IRC | 06:44 | |
| *** abderrahim32 has joined #buildstream | 06:45 | |
| *** lsfranco has joined #buildstream | 07:07 | |
| *** slaf_ has joined #buildstream | 07:34 | |
| *** slaf has quit IRC | 07:36 | |
| *** slaf_ is now known as slaf | 07:36 | |
| *** juergbi has quit IRC | 08:53 | |
| *** juergbi has joined #buildstream | 08:53 | |
| laurence | juergbi, thanks - I wanted to add cs-shadow so that he could edit the page for the Gathering in January | 12:17 |
|---|---|---|
| laurence | juergbi, but i can't quite remember how it works for the GNOME wiki | 12:18 |
| juergbi | laurence: anyone that is already listed on that page can add other users to the list | 12:18 |
| juergbi | do you know cs-shadow's GNOME wiki username? | 12:19 |
| laurence | juergbi, I believe it's simply ChandanSingh - looking at https://wiki.gnome.org/ChandanSingh | 12:19 |
| laurence | which of course doesn't exist yet but is the page cs-shadow created | 12:20 |
| juergbi | I added him to the list | 12:21 |
| laurence | thanks for the list, I just wasn't sure where that was kept | 12:21 |
| laurence | oh, cheers juergbi :) | 12:21 |
| cs-shadow | laurence, juergbi: thanks! I can confirm that I am able to update the wiki now | 12:29 |
| juergbi | yw | 12:29 |
| *** max has joined #buildstream | 12:38 | |
| *** nimish has joined #buildstream | 13:40 | |
| *** max has quit IRC | 14:15 | |
| *** max has joined #buildstream | 16:47 | |
| *** bochecha has joined #buildstream | 17:16 | |
| *** max has quit IRC | 17:38 | |
| *** tristan has quit IRC | 18:02 | |
| *** max has joined #buildstream | 18:32 | |
| *** nimish has quit IRC | 19:13 | |
| *** bochecha has quit IRC | 20:03 | |
| *** max_ has joined #buildstream | 20:24 | |
| *** max has quit IRC | 20:24 | |
| *** max_ is now known as max | 20:24 | |
| *** juergbi has quit IRC | 20:30 | |
| *** tristan has joined #buildstream | 21:33 | |
| *** ChanServ sets mode: +o tristan | 21:57 | |
| tristan | cs-shadow, I'm looking at pipelines... seems you're doing the same thing as me in https://gitlab.com/BuildStream/buildstream/tree/tristan/use-tox | 21:59 |
| cs-shadow | tristan: ah! I didn't realize you were looking at it as well. I was playing with it as I wanted to include a demo in one of the ML threads I started about testing. | 22:03 |
| cs-shadow | I want to avoid site-packages if possible so was playing trial and run with the CI :) | 22:04 |
| cs-shadow | I guess it would make sense to not duplicate effort now? | 22:04 |
| tristan | cs-shadow, I had to enable that still in order to test ostree | 22:04 |
| tristan | it's annoying, you cant conditionally say "dont try ostree if ostree is not installed", at least not to the linter | 22:05 |
| tristan | unless maybe we baked the .pylintrc | 22:05 |
| tristan | cs-shadow, I was looking into it in the hope it can make tests run more consistently on peoples laptops, and maybe help the situation with the images | 22:07 |
| cs-shadow | hmm, in https://gitlab.com/BuildStream/buildstream/pipelines/41557281, I managed to run all integration tests without using site packages, but in order to install pygobject we need its build deps | 22:07 |
| tristan | cs-shadow, i.e. we could use a pip freeze for different environments for testing | 22:07 |
| tristan | oh so you did `pip3 install gobject PyGObject` ? | 22:08 |
| tristan | or you put those in your deps ? | 22:08 |
| cs-shadow | yes, I have put it as a pure python dependency, and included in additional plugin-requirements.txt | 22:08 |
| cs-shadow | something like https://gitlab.com/BuildStream/buildstream/blob/5f1de22da3a54adf2587e953432c150da10da849/tox.ini | 22:09 |
| tristan | oh that ! nice approach | 22:10 |
| cs-shadow | It needs its build deps, like https://gitlab.com/BuildStream/buildstream/blob/5f1de22da3a54adf2587e953432c150da10da849/.gitlab-ci.yml#L39, but we can easily put those in base images if we go with this approach | 22:10 |
| tristan | that's even better, because I'd like to have a frozen set of deps and then we get the flexibility we wanted, and allow dynamic installation in CI | 22:11 |
| tristan | then we could just use pip freeze or smth to generate a deps file | 22:11 |
| cs-shadow | yep, that's exactly what I am doing on my branch | 22:12 |
| tristan | right, it needs like python3-venv, and I don't know what it is on fedora | 22:12 |
| tristan | cs-shadow, sounds like I already like your branch better than mine haha | 22:12 |
| cs-shadow | :) I can tidy it up by tomorrow and then I'll request you to have a look | 22:13 |
| tristan | you seem further along... I ran them with all three 3.5,3.6 and 3.7 versions | 22:13 |
| tristan | lemme see what you should take from my branch | 22:13 |
| tristan | cs-shadow, https://gitlab.com/BuildStream/buildstream/blob/tristan/use-tox/tox.ini | 22:14 |
| tristan | cs-shadow, first, notice `skip_missing_interpreters` | 22:15 |
| tristan | cs-shadow, I needed passenv in case I have locally built python bindings | 22:16 |
| tristan | as my ostree bindings from my distro are too old | 22:16 |
| tristan | cs-shadow, most importantly, skip_missing_interpreters = true means that most people will just get a clean exit from tox | 22:17 |
| tristan | and most people will only have one python installed | 22:17 |
| tristan | if they have multiple, they can run one batch with `tox -e py36 -- [pytest args]` like that | 22:17 |
| tristan | cs-shadow, the one thing I didnt really check yet is if we need to rework coverage | 22:18 |
| cs-shadow | tristan: that's fair, `skip_missing_interpreters = true` makes sense. And good tip about GI_TYPELIB_PATH, I wasn't aware of that | 22:18 |
| tristan | I have an updated CONTRIBUTING.rst: https://gitlab.com/BuildStream/buildstream/commit/943f6f1632475a5c0830d54115e073bf73eedabd | 22:20 |
| tristan | cs-shadow, So maybe we can share the work ? | 22:20 |
| cs-shadow | tristan: that's really good | 22:21 |
| cs-shadow | also, coverage should be unaffected AFAIU | 22:21 |
| tristan | I can investigate whether we are collating the coverage reports correctly, and fix that if it doesnt work with multiple runs | 22:21 |
| tristan | what I can imagine, is if tox runs multiple environments, only the last .coverage report is used | 22:22 |
| cs-shadow | ah! that I am not sure of. I meant it should be fine in the CI setup | 22:22 |
| tristan | I imagine it will be fine in the CI setup too | 22:23 |
| cs-shadow | where we only run one env per job | 22:23 |
| tristan | interestingly all the args are automatically picked up by setup.cfg | 22:23 |
| tristan | I guess pytest reads that directly | 22:23 |
| cs-shadow | https://stackoverflow.com/a/22256532 seems like there's an option | 22:23 |
| tristan | so ./setup.py test still works to test against your host environment | 22:23 |
| cs-shadow | yeah, pytest looks for pytest.ini, tox.ini and setup.cfg, in that order (I think) | 22:24 |
| tristan | so only adding a tox.ini on top of everything makes tox usable as a frontend to the existing stuff | 22:25 |
| tristan | it's nicely simple anyway | 22:25 |
| cs-shadow | exactly, so people's existing workflow won't break just because of adding tox. Instead, they'll now also have a simpler way of running tests in virtual envs | 22:27 |
| tristan | Right, but direct people to tox by default in the guides, in the hope it is overall less hassle :) | 22:28 |
| cs-shadow | agree | 22:30 |
| tristan | cs-shadow, we'll need a command line to install all the deps for ostree/pygobject | 22:31 |
| tristan | that is a different way to install, I only learned it was possible this week | 22:31 |
| tristan | (I think last time I tried, the gobject python thing was a source download with a failing build) | 22:32 |
| cs-shadow | tristan: yep, that makes sense. I found the necessary packages from https://pygobject.readthedocs.io/en/latest/devguide/dev_environ.html#devenv but that page talks about more than just installing the deps | 22:35 |
| cs-shadow | so including a short one-liner with reference to this page would probably be okay | 22:35 |
| cs-shadow | unfortunately, the one-liner is going to look different based on the operating system/distro | 22:37 |
| tristan | cs-shadow, that is the same page I stumbled upon indeed | 22:38 |
| cs-shadow | would be ideal if we can request these folks to publish wheels for their package | 22:38 |
| cs-shadow | at least for linux perhaps | 22:39 |
| tristan | which ? | 22:39 |
| tristan | all of them ? | 22:39 |
| cs-shadow | pygobject i mean | 22:39 |
| cs-shadow | that's the only package with non-python deps | 22:39 |
| cs-shadow | (except for psutil, but that only requires a compiler) | 22:40 |
| tristan | ah them yeah... I don't think it is typical to use pygobject installed from pip | 22:40 |
| cs-shadow | fair enough | 22:42 |
| tristan | well, I dont know what your chances are of getting them to publish wheels | 22:43 |
| tristan | Anyway, eliminating the site packages for the sake of running tests is certainly desirable | 22:44 |
| tristan | seems I cannot trust my python path | 22:44 |
| tristan | I had to uninstall pytest which I previously installed with `--user`, for my py35 batch to pass | 22:45 |
| cs-shadow | yeah, and if someone really wants to use site packages for whatever reason, they can always do so by a command line flag | 22:46 |
| cs-shadow | tristan: the pytest failure might have been caused in case the newer version of pytest causes issues with our test suite | 22:46 |
| cs-shadow | but that's just a guess as I haven't had the problem yet | 22:46 |
| tristan | I am using latest I think, anyway I don't know why it chose a host pytest | 22:47 |
| cs-shadow | might be the way tox discovers site pacakges | 22:49 |
| cs-shadow | not sure | 22:49 |
| tristan | I hope the developer setup experience is not too badly impacted by the installation of these | 22:51 |
| tristan | alternatively, I was really hoping to find a way to just tell pylint to skip ostree where it's unavailable | 22:52 |
| cs-shadow | that also makes sense, especially since that's how other plugins behave | 22:53 |
| tristan | right, we do that everywhere else | 22:57 |
| tristan | we could split the linting out of the tests, that seems to make sense anyway | 22:57 |
| tristan | we could run the linting once in parallel from the rest of the tests | 22:58 |
| cs-shadow | sounds good, it would also improve the developer experience as folks will be able to run just the tests wiyhout linting | 22:59 |
| tristan | another benefit is that I have a feeling the coverage thing is capturing the linter, and any chance of that is eliminated anyway | 23:02 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!