Hi Liliana, Liliana Marie Prikler skribis: > Am Mittwoch, den 29.09.2021, 15:16 +0200 schrieb Ludovic Courtès: >> Hi there! >> >> I’d rather go with zimoun’s original patch, which is focused and does >> nothing more than what was originally intended, which is to factorize >> the procedure. I’ll go ahead and apply it shortly if there are no >> objections. > I have trouble understanding this paragraph. What exactly is "this > patch" and what do you mean by "factorizing"? If it means moving > computed-origin-method elsewhere, then yes, for a short-time solution > only moving it is a wise choice in my opinion, OK, I agree too. > but zimoun and I still disagree on the target. zimoun says (guix > packages) for reasons unknown to me, whereas I say (gnu packages), > because it's closer to where it's used and doesn't imply that this is > going to be a part of the (guix) download schemes anytime soon. (gnu packages) is higher-level: it’s part of the distro and includes CLI helpers such as ‘specification->package’. So I think (guix …) is somewhat more appropriate. (That said, what matters more to me is how we’re going to replace it with a proper solution.) [...] >> A better solution IMO would be to improve the ‘snippet’ mechanism in >> the first place. ‘computed-origin-method’ improves on it in two >> ways: (1) lazy evaluation of the gexp, and (2) allows the use of a >> different base name. >> >> I would think #2 is addressed by the ‘file-name’ field (isn’t it?). >> >> As for #1, it can be addressed by making the ‘snippet’ field delayed >> or thunked. It’s a one line change; the only thing we need is to >> measure, or attempt to measure, the impact it has on module load >> time. >> >> Thoughts? > This would work for packages, whose source are some base source with > patches or snippets applied, as is indeed the case for linux and > icecat. However, there are also other potential uses for computed > origins. It’s hard for me to talk about potential uses in the abstract. :-) There might be cases where an origin simply isn’t the right tool and one would prefer ‘computed-file’ or something else. It really depends on the context. [...] > I think that some version of `computed-origin-method' will eventually > need to become public API as such packages may not always be best > described as "a base package with a snippet". If we had recursive > origins – i.e. origins, that can take origins as inputs – we might be > able to do some of that, but I don't think it would necessarily work > for linux-libre or icecat, as with those you don't want the tainted > versions to be kept around. Perhaps this could be worked around by not > interning the intermediate origins, but only using their file-names > inside the temporary directory in which the snippet is applied? “Recursive origins” are a bit of a stretch as a concept IMO; what you describe is a case where I’d probably use ‘computed-file’ instead. > Another thing is that the final act of the linux-libre promise is not > the packing of the tarball, but the deblob-check. Guix currently lacks > a way of modeling such checks in their origin, but I'd argue it would > need one if we wanted to do computed origins via snippets. This is not > required by icecat and so one "simplification" could be that computed- > origin-method would not require the user to create a tarball, but > instead simply provide a name for the tarball and a directory to create > it from (via a promise again). Ah, I had overlooked that ‘deblob-check’ bit. It could be that allowing for custom pack-and-repack procedures would be enough to address it. > A combination of the above might make computed origins obsolete for > good, but the question remains whether that is a better design. What > do y'all think? The design goal is to have clearly identified types: , , . For each of these, we want some flexibility: build system, origin method, etc. However, beyond some level of stretching, it may be clearer to just use the catch-all ‘computed-file’ or to devise a new type. After all, that’s how came to be (we could have used instead with a suitable build system). There’s a tension between “purely declarative” and “flexible”, and it’s about striking a balance, subjectively. Hope that makes sense! Ludo’.