IRC channel logs


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
<rekado>we should probably export it.
<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
<civodul>it shouldn't be this hard
<civodul> only has simple examples
<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>current manifest:
<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
<civodul> <>
<civodul>ah, not quite the same i guess
<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>I’ll give that a try
<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>I’m still refining it.
<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?
<civodul>*does it
<rekado>no, something else :)
<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>I did demonstrate this with R
<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>something similar about Emacs packages raised by Nicolas
<zimoun>the transformations are not as straightforward as we often tell. ;-)
<civodul>and python-minimal
<civodul>it's not a limitation of transformations per se, but rather the fact that there are often several related packages
<civodul>and you want to change them all
<civodul>not sure how we could improve on that
<civodul>rekado: in other news, 5.6M -> 192K on those manifests (patch coming)
<rekado>thanks for working on this
<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>civodul``: I am puzzled by <>
<zimoun>Any idea why “build hello” from 2020 breaks when all the necessary is already in my store?
<zimoun>Is it related to NVMe? As <>
<zimoun>But I miss why bootstrap-binaries are involved with “build hello”. Any explanations?
<civodul>zimoun: is weird
<civodul>just replied
<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… « expired on 05/28/2022 and is pending renewal or deletion» Ahaha!
<civodul>not on SWH?
<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.