Re: Creating local variation of match-theme

[Jack Hill]

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