Re: Creating local variation of match-theme
Jack Hill writes:
> Thanks Marius!
>
> On Wed, 18 Dec 2019, Marius Bakke wrote:
>
>> It's not pretty, but you could create a package that takes "match-theme"
>> as an input and makes the necessary adjustments.
>>
>> See the 'mariadb/fixed-install-db' variant added in
>> 9077cf68ec57c0303ef7746e203c3fe5ed041add for an example.
>
> I tried this approach first, and find the results acceptable for this
> purpose. This technique seems most applicable when what needs to modified
> is a text file. I ended up with this package definition:
>
> ```
> (package
> (inherit matcha-theme)
> (native-inputs '())
> (inputs `(("matcha-theme" ,matcha-theme)))
> (outputs '("out"))
> (build-system trivial-build-system)
> (arguments
>`(#:modules ((guix build utils))
> #:builder
> (begin
> (use-modules ((guix build utils)))
> (let ((upstream-theme (assoc-ref %build-inputs "matcha-theme"))
> (out (assoc-ref %outputs "out")))
> (copy-recursively upstream-theme out)
> (substitute* (find-files out "\\.css$")
> (("abb9b6") "859900"))
> (synopsis "jackhill's version of the matcha-theme"))
> ```
>> Another "cleaner" approach could be to use 'computed-file' to create a
>> patched source tarball, and pass that as the source in your local
>> variant.
>
> I have not yet tried this. I should because, as you point out, this is
> "cleaner", and would work in situations where what needs to be modified in
> compiled into an opaque object in the output.
>
> However, without trying this, I don't see how it would work better than
> using a snippet in the origin definition. Or perhaps you meant to created
> the patched source tarball from the output of the upstream matcha-theme
> package?
>
> Either way, I think I'm still left with the question of how can we make
> modifying packages easier without the need to resort to kludges.
'substitute-keyword-arguments' and 'snippets' do make it pretty easy,
but as you found it does not work with 'trivial-build-system'.
Perhaps we should just discourage the latter entirely: "matcha-theme"
can easily be rewritten to use 'gnu-build-system' instead by deleting or
overriding the unnecessary phases.
Feel free to submit a patch that does just that! :-)
signature.asc
Description: PGP signature
Re: Creating local variation of match-theme
Thanks Marius!
On Wed, 18 Dec 2019, Marius Bakke wrote:
It's not pretty, but you could create a package that takes "match-theme"
as an input and makes the necessary adjustments.
See the 'mariadb/fixed-install-db' variant added in
9077cf68ec57c0303ef7746e203c3fe5ed041add for an example.
I tried this approach first, and find the results acceptable for this
purpose. This technique seems most applicable when what needs to modified
is a text file. I ended up with this package definition:
```
(package
(inherit matcha-theme)
(native-inputs '())
(inputs `(("matcha-theme" ,matcha-theme)))
(outputs '("out"))
(build-system trivial-build-system)
(arguments
`(#:modules ((guix build utils))
#:builder
(begin
(use-modules ((guix build utils)))
(let ((upstream-theme (assoc-ref %build-inputs "matcha-theme"))
(out (assoc-ref %outputs "out")))
(copy-recursively upstream-theme out)
(substitute* (find-files out "\\.css$")
(("abb9b6") "859900"))
(synopsis "jackhill's version of the matcha-theme"))
```
Another "cleaner" approach could be to use 'computed-file' to create a
patched source tarball, and pass that as the source in your local
variant.
I have not yet tried this. I should because, as you point out, this is
"cleaner", and would work in situations where what needs to be modified in
compiled into an opaque object in the output.
However, without trying this, I don't see how it would work better than
using a snippet in the origin definition. Or perhaps you meant to created
the patched source tarball from the output of the upstream matcha-theme
package?
Either way, I think I'm still left with the question of how can we make
modifying packages easier without the need to resort to kludges.
Best,
Jack
Re: Creating local variation of match-theme
Hi,
It's been a few days, so I was wondering if anyone had thoughts on the
following:
Best,
Jack
On Sun, 8 Dec 2019, Jack Hill wrote:
Hi Guix,
I'd like to create a local variation of the matcha-theme package with one of
the colors changed to suit my taste. Rather than make the change in my clone
of the git repository, which could then become outdated, I thought I would
try to make the change programatically as part of the package definition. I
decided to make my change in a snippet as part of the origin specification
because that seemed to logically fit with what I was trying to do (build a
package with modified source) and because matcha-theme uses the trivial build
system, which I don't believe has the concept of phases, so it wasn't clear
how I would add a phase to make my change during the build. I came up with
the following package definition:
```
(package
(inherit matcha-theme)
(source (origin
(inherit (package-source matcha-theme))
(modules '((guix build utils)))
(snippet
'(begin
(substitute* (find-files "." "\\.css$")
(("abb9b6") "859900"))
(synopsis "jackhill's version of the matcha-theme"))
```
Unfortunately, after building my modified source tarball correctly, the
package build fails. I believe this is because matcha-theme's
trivial-build-system recipe expects a source checkout and not a tarball, and
doesn't have the logic to expand the tarball that, e.g., the gnu-build-system
provides.
The build log contains the following:
```
@ build-started
/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv -
x86_64-linux
/var/log/guix/drvs/rq//x5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv.bz2
28285
Backtrace:
4 (primitive-load "/gnu/store/j01a49zzlrn7fyr2x7ibxyqsph5?")
In ice-9/eval.scm:
191:35 3 (_ #f)
619:8 2 (_ #(#(#(#(#(# ?) ?) ?) ?) ?))
In
/gnu/store/ygivy1fvr7gbyva4z22b7vzzps1krbq5-module-import/guix/build/utils.scm:
343:27 1 (_ "/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj07-matcha?" ?)
In unknown file:
0 (copy-file "/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj0?" ?)
ERROR: In procedure copy-file:
In procedure copy-file: Is a directory
`/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj07-matcha-theme-2019-11-02.tar.xz'
-> `/tmp/guix-build-matcha-theme-2019-11-02.drv-0'
builder for
`/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv'
failed with exit code 1
@ build-failed
/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv - 1
builder for
`/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv'
failed with exit code 1
```
For reference, matcha-theme's builder is:
```
(arguments
'(#:modules ((guix build utils))
#:builder
(begin
(use-modules (guix build utils))
(let* ((out (assoc-ref %outputs "out"))
(source (assoc-ref %build-inputs "source"))
(bash (assoc-ref %build-inputs "bash"))
(coreutils (assoc-ref %build-inputs "coreutils"))
(themesdir (string-append out "/share/themes")))
(setenv "PATH"
(string-append coreutils "/bin:"
(string-append bash "/bin:")))
(copy-recursively source (getcwd))
(patch-shebang "Install")
(mkdir-p themesdir)
(invoke "./Install" "-d" themesdir)
#t
```
This leaves me with two questions:
How should I accomplish what I want to do (change one of the colors in
matcha-theme for local use)?
If I am right about trivial-build-system (that it makes it more difficult to
create modified packages compared to other build systems), should we try to
avoid using it in gnu/packages to ensure people have the easiest time
exercising their software freedom?
Best,
Jack
