IRC channel logs
2022-05-31.log
back to list of logs
<rekado>perhaps what I need is a conditional replacement; the rewrite machinery replaces unique nodes in the graph, so that any user of that node will use the replacement instead. <rekado>I’m now using CUT? and #:deep? #false, but I don’t know if this is correct <rekado>I feel that it’s wrong, because I do want propagated inputs to be rewritten; this is Python after all, so everything is propagated. <zimoun>rekado: why not ’package-with-explicit-python’? <zimoun>instead of passing python2 to have ’package-with-python2’, you can construct ’package-with-python3.8’, no? <rekado>oh, I keep forgetting about tools like this <zimoun>Well, I do not know what is best: refactorize with similar as package-with-explicit-ocaml and maybe have a way for a programmatic transformation **or** keep the wild because the build systems are too specific. <rekado>I’m probably doing something stupid, but I can’t seem to get at this procedure, not even with (@@ (guix build-system python) package-with-explicit-python) <civodul>rekado: that's prolly because it's inlined <rekado>I think this kind of thing would make for a good blog post / cookbook entry <rekado>the next problem I stumbled into is python-matplotlib’s use of `(,python "tk"), which is not replaced by the package transformation <rekado>trying to work around this with (modify-inputs … (replace "python:tk" `(,other-python "tk"))) <rekado>hmm, this doesn’t seem to work, because the input is not labelled “python:tk” <rekado>it has the label “python” but also comes with an output. <rekado>replace-input only accepts a NAME argument, so I can’t match on python’s tk output and replace *that* with the new python’s "tk" output. <rekado>not particularly pretty, but seems to work so far <civodul>i think modify-inputs should be able to replace that <civodul>there was an issue that was fixed recently <rekado>it’s just as good, though. This means I should be able to do (modify-inputs … (replace "python" my-python)) and it would also replace those instances where python’s tk output is used. <rekado>next problem is packages like pybind11; they produce Python modules but do not use the python-build-system. <civodul>you're trying to substitute the default python with another one, but just in selected places, is that correct? <rekado>only for those packages that end up providing Python modules. <civodul>the package-mapping trick you showed yesterday didn't achieve that? <rekado>obviously I can’t *just* look at python-build-system <rekado>and I can’t look at the provided files <rekado>so now I’m adding a list of packages that should also be considered “Python packages” <rekado>I still run into a bunch of problems with several builds, though <rekado>the whole thing isn’t quite as easy as I made it out to be :) <civodul>does is have to do with the Python 2 purge? <rekado>I convinced one of my colleagues to give Guix a try <rekado>and they like to stay on a slightly older version of Python without having to give up on latest Python modules <civodul>i can picture the conversation: "even changing the Python that your packages use is trivial, you'll see!" <rekado>Python has the severe disadvantage of being so very popular <civodul>often --with-input is too aggressive <rekado>so naively swapping out python causes a rebuild of almost everything: librsvg, gtk+, etc <civodul>we'd need a kind of package-input-rewriting that can be told to stop at some level <rekado>another complication with modify-inputs: python-wrapper vs python <rekado>python-wrapper is often needed because we run “python” (not “python3”) in build phases <rekado>but “python-wrapper” does not have a “tk” output whereas “python” does. <zimoun>the transformations are not as straightforward as we often tell. ;-) <civodul>it's not a limitation of transformations per se, but rather the fact that there are often several related packages <civodul>not sure how we could improve on that <civodul>rekado: in other news, 5.6M -> 192K on those manifests (patch coming) <civodul>for my home profile it goes from 316K to 112K <civodul>this is very much an optimization for R and Python folks i guess :-) <zimoun>Any idea why “build hello” from 2020 breaks when all the necessary is already in my store? <zimoun>But I miss why bootstrap-binaries are involved with “build hello”. Any explanations? <zimoun>civodul: thanks. We are working Nicolas on reproducing analysis from 2020 as an attempt to demonstrate the feasability in a paper :-) <civodul>oh i see, so better have this solved :-) <zimoun>Oh, we are getting a beautiful link rot… «flowrepository.org expired on 05/28/2022 and is pending renewal or deletion» Ahaha! <zimoun>nah because it is data, not source code. Well, it is depressing… because source code is much easier than data when speaking about reproducibility. And source code is already a big task almost impossible <zimoun>civodul: once in REPL, build using run-in-store raises the same error.