| Message ID | 20200923161253.2378-1-ludo@gnu.org |
|---|---|
| Headers | show |
Hi, On Wed, 23 Sep 2020 at 18:23, Ludovic Courtès <ludo@gnu.org> wrote: > Concretely, the following commands had no effect thus far: > > guix build python-itsdangerous --with-input=python=python2 > guix build hello --with-input=gcc=gcc-toolchain@10 > > In both cases, this is because the input we want to change is > an implicit input. This patch set fixes that, and it fixes > <https://issues.guix.gnu.org/42156> as a side effect. Awesome! Therefore, 'package-with-explicit-python' & co. are becoming obsolete (or almost), right? > This opens new possibilities. ‘--with-input=python=python2’ is one > of them, but ‘--with-input=gcc=gcc-toolchain@10’ is not (it fails > to build for obscure reasons that I’ll fix in ‘core-updates’, and > it rebuilds the world anyway, which is not practical). Another Rebuilding the world, maybe. :-) It is interesting in the HPC context where one would like use an "optimized" compiler, isn't? Thank you. I will give it a try for my use cases. :-) All the best, simon
Hi! zimoun <zimon.toutoune@gmail.com> skribis: > On Wed, 23 Sep 2020 at 18:23, Ludovic Courtès <ludo@gnu.org> wrote: > >> Concretely, the following commands had no effect thus far: >> >> guix build python-itsdangerous --with-input=python=python2 >> guix build hello --with-input=gcc=gcc-toolchain@10 >> >> In both cases, this is because the input we want to change is >> an implicit input. This patch set fixes that, and it fixes >> <https://issues.guix.gnu.org/42156> as a side effect. > > Awesome! > > Therefore, 'package-with-explicit-python' & co. are becoming obsolete > (or almost), right? Good question, we’d have to check on a case-by-case basis. ‘package-input-rewriting’ is coarser-grain: it can potentially rewrite ‘python’ dependencies deeper in the graph than ‘package-with-explicit-python’. >> This opens new possibilities. ‘--with-input=python=python2’ is one >> of them, but ‘--with-input=gcc=gcc-toolchain@10’ is not (it fails >> to build for obscure reasons that I’ll fix in ‘core-updates’, and >> it rebuilds the world anyway, which is not practical). Another > > Rebuilding the world, maybe. :-) It is interesting in the HPC context > where one would like use an "optimized" compiler, isn't? Like I wrote, ‘--with-input=gcc=gcc-toolchain@10’ (or similar) isn’t practical: you’d have to rebuild the world. What I envision for the use case where you want to build a specific package set with a different toolchain is to have a ‘--with-toolchain=PACKAGE=TOOLCHAIN’ option. That would rebuild PACKAGE with TOOLCHAIN. Then it would either rebuild all its dependents (as per ‘--with-input’) or graft the rebuilt package (as per ‘--with-graft’). The latter may not always be a viable option though, so I don’t know. In fact I think it would be nice if the graft vs. rebuild choice could be made independently for all the transformation options. > Thank you. I will give it a try for my use cases. :-) Awesome, let me know how it goes! Thank you, Ludo’.
On Wed, Sep 23, 2020 at 10:51:21PM +0200, Ludovic Courtès wrote: > Hi! > > zimoun <zimon.toutoune@gmail.com> skribis: > > > On Wed, 23 Sep 2020 at 18:23, Ludovic Courtès <ludo@gnu.org> wrote: > > > >> Concretely, the following commands had no effect thus far: > >> > >> guix build python-itsdangerous --with-input=python=python2 > >> guix build hello --with-input=gcc=gcc-toolchain@10 > >> > >> In both cases, this is because the input we want to change is > >> an implicit input. This patch set fixes that, and it fixes > >> <https://issues.guix.gnu.org/42156> as a side effect. > > > > Awesome! > > > > Therefore, 'package-with-explicit-python' & co. are becoming obsolete > > (or almost), right? > > Good question, we’d have to check on a case-by-case basis. > ‘package-input-rewriting’ is coarser-grain: it can potentially rewrite > ‘python’ dependencies deeper in the graph than > ‘package-with-explicit-python’. > IIRC part of the reason for python-minimal was to build tcl/tk and xorg. We don't really want to rebuild deep enough to rebuild xorg with python2. I'm struggling to find a use-case but going as deep as sqlite shouldn't be a problem. > >> This opens new possibilities. ‘--with-input=python=python2’ is one > >> of them, but ‘--with-input=gcc=gcc-toolchain@10’ is not (it fails > >> to build for obscure reasons that I’ll fix in ‘core-updates’, and > >> it rebuilds the world anyway, which is not practical). Another > > > > Rebuilding the world, maybe. :-) It is interesting in the HPC context > > where one would like use an "optimized" compiler, isn't? > > Like I wrote, ‘--with-input=gcc=gcc-toolchain@10’ (or similar) isn’t > practical: you’d have to rebuild the world. > > What I envision for the use case where you want to build a specific > package set with a different toolchain is to have a > ‘--with-toolchain=PACKAGE=TOOLCHAIN’ option. That would rebuild PACKAGE > with TOOLCHAIN. Then it would either rebuild all its dependents (as per > ‘--with-input’) or graft the rebuilt package (as per ‘--with-graft’). > The latter may not always be a viable option though, so I don’t know. > > In fact I think it would be nice if the graft vs. rebuild choice could > be made independently for all the transformation options. > > > Thank you. I will give it a try for my use cases. :-) > > Awesome, let me know how it goes! > > Thank you, > Ludo’. > > >
Hi Ludo, On Wed, 23 Sep 2020 at 18:12, Ludovic Courtès <ludo@gnu.org> wrote: > Concretely, the following commands had no effect thus far: > > guix build python-itsdangerous --with-input=python=python2 > guix build hello --with-input=gcc=gcc-toolchain@10 > > In both cases, this is because the input we want to change is > an implicit input. This patch set fixes that, and it fixes > <https://issues.guix.gnu.org/42156> as a side effect. Maybe I am doing wrong and I miss something. For example, I want to build the package ’emacs-helm’ –which does not (directly) depends on the package ’emacs’– using the package ’emacs-next’ (changing the Emacs VM from 27 to 28 in this case). --8<---------------cut here---------------start------------->8--- $ ./pre-inst-env guix build emacs emacs-next /gnu/store/7kr0pg7gwhc31q4iq5vbnm5n99srhp84-emacs-next-28.0.50.1-0.2ea3466 /gnu/store/q3c6y4ccj3li5gfdcbyz24n466fnipp1-emacs-27.1 $ cat /tmp/manif.scm (specifications->manifest '("emacs-helm")) $ ./pre-inst-env guix build -m /tmp/manif.scm /gnu/store/ka9lph0hpzaky0sa52zf09469apkhb68-emacs-helm-3.6.5 $ ./pre-inst-env guix build -m /tmp/manif.scm --with-input=emacs=emacs-next /gnu/store/ka9lph0hpzaky0sa52zf09469apkhb68-emacs-helm-3.6.5 --8<---------------cut here---------------end--------------->8--- I miss why the hash is the same. I was expecting a different one, as with your ’hello’ example (that I reproduce exactly). What do I miss? Note it is the same with: --8<---------------cut here---------------start------------->8--- $ ./pre-inst-env guix build emacs-helm --with-input=emacs=emacs-next /gnu/store/ka9lph0hpzaky0sa52zf09469apkhb68-emacs-helm-3.6.5 --8<---------------cut here---------------end--------------->8--- Well, I am trying to provide an example to [1] because your patch set supersedes it, somehow. [1] <http://issues.guix.gnu.org/41732#7> (I have not yet tried the build transformation at the manifest level.) All the best, simon
Hi zimoun, zimoun <zimon.toutoune@gmail.com> skribis: > I miss why the hash is the same. I was expecting a different one, as > with your ’hello’ example (that I reproduce exactly). What do I miss? > > Note it is the same with: > > $ ./pre-inst-env guix build emacs-helm --with-input=emacs=emacs-next > /gnu/store/ka9lph0hpzaky0sa52zf09469apkhb68-emacs-helm-3.6.5 That’s because ‘emacs-helm’ depends on ‘emacs-minimal’, not ‘emacs’: --8<---------------cut here---------------start------------->8--- $ guix graph --path -t bag emacs-helm emacs guix graph: error: no path from 'emacs-helm@3.6.5' to 'emacs@27.1' $ guix graph --path -t bag emacs-helm emacs-minimal emacs-helm@3.6.5 emacs-minimal@27.1 --8<---------------cut here---------------end--------------->8--- Does it work for you if you do ‘--with-input=emacs-minimal=emacs-next’? HTH, Ludo’.
On Sat, 26 Sep 2020 at 15:53, Ludovic Courtès <ludo@gnu.org> wrote:
> Does it work for you if you do ‘--with-input=emacs-minimal=emacs-next’?
Ahah! Stupid me! :-)
Yes it works for me. And it does what I wanted when discussing the
lengthy and controversial package parameters. Thank you!
Cheers,
simon
Hello Guix! This patch set aims to hit two bird hunters with one stone: initially my goal was to fix <https://issues.guix.gnu.org/42156>, which has become a hindrance to the use of package transformation options, but it also ends up addressing the fact that those options did not, until now, rewrite implicit dependencies. Concretely, the following commands had no effect thus far: guix build python-itsdangerous --with-input=python=python2 guix build hello --with-input=gcc=gcc-toolchain@10 In both cases, this is because the input we want to change is an implicit input. This patch set fixes that, and it fixes <https://issues.guix.gnu.org/42156> as a side effect. This opens new possibilities. ‘--with-input=python=python2’ is one of them, but ‘--with-input=gcc=gcc-toolchain@10’ is not (it fails to build for obscure reasons that I’ll fix in ‘core-updates’, and it rebuilds the world anyway, which is not practical). Another thing that I find interesting is: $ guix build hello --with-graft=glibc=glibc@2.29 /gnu/store/6jv7icpjbl3pvj24db2q2fmdly9vgp4d-hello-2.10 $ /gnu/store/6jv7icpjbl3pvj24db2q2fmdly9vgp4d-hello-2.10/bin/hello Saluton, mondo! $ LD_TRACE_LOADED_OBJECTS=yes /gnu/store/6jv7icpjbl3pvj24db2q2fmdly9vgp4d-hello-2.10/bin/hello linux-vdso.so.1 (0x00007ffcc87f8000) libgcc_s.so.1 => /gnu/store/1sqr5fa6jbksqmi7hibqaffixy3b1j0y-gcc-7.5.0-lib/lib/libgcc_s.so.1 (0x00007f3f36c3c000) libc.so.6 => /gnu/store/i4iqkjx34r3nmwwblfmkbsbsd3pgapfp-glibc-2.29/lib/libc.so.6 (0x00007f3f36a82000) /gnu/store/i4iqkjx34r3nmwwblfmkbsbsd3pgapfp-glibc-2.29/lib/ld-linux-x86-64.so.2 (0x00007f3f36c57000) It “relinks” the package against a different libc, assuming the ABI is compatible (this particular example downgrades glibc, probably less useful in the real world than upgrading; it works for ‘hello’ but not for ‘inkscape’ due to ABI differences.) Feedback welcome! Ludo’. Ludovic Courtès (4): packages: 'package-mapping' can recurse on implicit inputs. packages: 'package-input-rewriting/spec' can rewrite implicit dependencies. packages: 'package-mapping' correctly recurses into 'replacement'. packages: 'package-input-rewriting' has a #:deep? parameter. doc/guix.texi | 28 ++++---- gnu/packages/guile.scm | 6 +- guix/packages.scm | 153 ++++++++++++++++++++++++++++------------ tests/guix-build.sh | 11 +++ tests/packages.scm | 149 ++++++++++++++++++++++++++++++++++++-- tests/scripts-build.scm | 12 +++- 6 files changed, 291 insertions(+), 68 deletions(-)