[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (Re-) Designing extractong-downaloder
From: |
Maxime Devos |
Subject: |
Re: (Re-) Designing extractong-downaloder |
Date: |
Wed, 23 Feb 2022 13:30:24 +0100 |
User-agent: |
Evolution 3.38.3-1 |
Hartmut Goebel schreef op wo 23-02-2022 om 09:57 [+0100]:
> TL;DR: What do you think about the idea of an „extracting dowloader“?
>
> I'm about pick up work on „extracting downloader“ and the rebar build
> system (for erlang), see <https://issues.guix.gnu.org/51061> for a first
> try, In the aforementioned issue some points came up regarding the basic
> design of the patch. Thus before starting to write code, I'd like to
> agree on a basic design.
Could the ‘extracting’ downloader be built on top of the regular
downloader? More concretely:
(package
(name "some-package-from-hex")
(source
(extract-from-hex
(origin
(method
"http://some-url-pointing-to-a-tarball-wrapped-in-a-tarball")
(sha256 (base32 <hash of the wrapper tarball>)))))
(build-system ...))
Here, 'extract-from-hex' would turn a file-like object into a <extract-
from-hex>, which lowers to some derivation extracting the tarball from
the tarball. (guix upstream) might need to be modified to support
<extract-from-hex>.
Also, is there some fundamental reason that hex.pm wraps tars inside
tars and only provides the wrapped tars, or could hex.pm be convinced
to also serve the underlying tars directly?
A benefit of delegating the actual downloading to url-fetch, is that
(guix scripts perform-download) would be used, so connections could be
cached.
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part