Re: "Parameterized Packages: The Project Completion Update"

d up his plate. So ... > On Mon, Oct 2, 2023 at 1:13 PM Munyoki Kilyungi > wrote: >> >> Andy Tai aliandika: >> >> > Not seen mentioned on this mailing list yet, so probably of interest: >> > GSOC project's final report: >> > https://blo

Re: "Parameterized Packages: The Project Completion Update"

;s final report: > > https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html > > > > Thanks for the effort!

Re: "Parameterized Packages: The Project Completion Update"

Andy Tai aliandika: > Not seen mentioned on this mailing list yet, so probably of interest: > GSOC project's final report: > https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html > Thanks for the effort! -- (Life is like a pencil that will surely

"Parameterized Packages: The Project Completion Update"

Not seen mentioned on this mailing list yet, so probably of interest: GSOC project's final report: https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html

Re: Update on Parameterized Packages

me of the > worries as I've been working on the project. > > Here is a new post covering the work that I've done in the past few weeks: > https://blog.lispy.tech/parameterized-packages-an-update.html > I would appreciate any questions, suggestions or comments! > > Cheers, > Sarthak. Looks very promising!

Update on Parameterized Packages

Hello guix-devel! I got a bunch of really helpful suggestions from the last thread <https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00156.html> about my Google Summer of Code project on bringing Package Parameterization to Guix <https://guix.gnu.org/blog/2023/parameterized-pac

Re: Discussion on Parameterized Packages

Hi, On jeu., 11 mai 2023 at 20:38, Sarthak Shah wrote: > https://blog.lispy.tech/2023/05/parameterized-packages.html > > I would really appreciate feedback on > (1) parameters you'd like to see in Guix > (2) the user interface for searching/installing/packaging with > parameters Just a quick re

Re: Discussion on Parameterized Packages

On 2023-05-13 20:26, david larsson wrote: [..] If this were a thing, Guix could avoid an LTS version, and just run GuixLTS via package-parameters - which would be, uhm fun, IMO :-) I do not mean LTS. I only meant a "stable" version, sorry for any confusion caused. Best regards, David

Re: Discussion on Parameterized Packages

On 2023-05-11 17:08, Sarthak Shah wrote: Hello Guix! I'll be working on bringing Parameterized Packages to Guix for GSoC 2023 under the guidance of Gábor and Pjotr. I've been a Guix user for a few years now as it works great for Common Lisp and Scheme projects, and I've a

Re: Discussion on Parameterized Packages

Am Donnerstag, dem 11.05.2023 um 20:38 +0530 schrieb Sarthak Shah: > Hello Guix! > I'll be working on bringing Parameterized Packages to Guix for GSoC > 2023 under the guidance of Gábor and Pjotr. I've been a Guix user for > a few years now as it works great for Common Lisp

Re: Discussion on Parameterized Packages

Sarthak Shah writes: > Hello Guix! > I'll be working on bringing Parameterized Packages to Guix for GSoC 2023 > under the guidance of Gábor and Pjotr. I've been a Guix user for a > few years now as it works great for Common Lisp and Scheme projects, and I've >

Discussion on Parameterized Packages

Hello Guix! I'll be working on bringing Parameterized Packages to Guix for GSoC 2023 under the guidance of Gábor and Pjotr. I've been a Guix user for a few years now as it works great for Common Lisp and Scheme projects, and I've always wanted to contribute to it as it has

Re: A plan for parameterized packages

Ludovic Courtès writes: > Hi, > > Denis 'GNUtoo' Carikli skribis: > >> The issue is that despite all that, the size of the images tend to >> increase too rapidly over time[1]. > > Yeah, that’s also the problem here: we have ‘guix size’ to profile a > package at one point in time, but it’s easy

Re: A plan for parameterized packages

Hi, On Fri, 20 Nov 2020 at 12:40, Ludovic Courtès wrote: > > The issue is that despite all that, the size of the images tend to > > increase too rapidly over time[1]. > > Yeah, that’s also the problem here: we have ‘guix size’ to profile a > package at one point in time, but it’s easy to unwilli

Re: A plan for parameterized packages

Hi, Denis 'GNUtoo' Carikli skribis: > Last time I looked into how LibreCMC/OpenWRT did that, they had much > more optimization than that. If I recall well, they use at least: > - sstrip to strip binaries as much as they could. sstrip produces > smaller binaries than with strip. > - compilation

Re: A plan for parameterized packages

On Sun, 15 Nov 2020 22:24:29 +0100 raingloom wrote: > Alpine already achieves an incredibly tiny install size by splitting > packages into many outputs. We could and should do the same. > As far as I know, they do not have parameterized packages. That also depends on how far you want to

Re: A plan for parameterized packages

> Hi Pierre, > Pierre Neidhardt skribis: > > One of the biggest struggle we had when discussing it was figuring out > > what to do about parameter propagation across dependencies. > > For instance, what if we want to build "all packages without X support"? > > This means that the parameter mu

Re: A plan for parameterized packages

Ludo, The self.options["openssl"].shared does set the option for openssl, but this is not different than providing `-o openssl:shared` on the command line; it uses this to determine which package was actually requested. Conan packages are also non-configurable in the end, stored as the hash of

Re: A plan for parameterized packages

Hi Stephen, (+Cc: guix-devel@gnu.org. You can post without being subscribed.) Stephen Christie skribis: > I have done a lot of work with the Conan package manager, a c++ > language package manager, that has grown in capability. It is not > fully functional, but works on the hash of the key par

Re: Make mutiple packages from outputs (Was: A plan for parameterized packages)

Hi, On Mon, 16 Nov 2020 at 19:25, 宋文武 wrote: >> And it is maybe an occasion to revisit the museum, i.e., the TODO file: [...] > I'd like to suggest another plan: Make every ‘output’ become a > object, so ‘propagated-build-inputs’ doesn’t need to change. Then we’ll > have something like debia

Re: A plan for parameterized packages

Hi, Danny Milosavljevic skribis: > For the embedded/flash rom side: Note: it’s great if it can help reduce closure size, but that’s not the goal. > * Enable/disable building the documentation. I really don't need a 40 MiB > manual stored onto a 16 MiB firmware flash chip. If that's better do

Re: A plan for parameterized packages

Hi, On Mon, 16 Nov 2020 at 13:03, Pierre Neidhardt wrote: > See point 7. about conflicts: > > https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00026.html Quoting for instance the 2 examples: For instance, use guile-2.2.4 instead of guile for all guile libraries, or use

Re: A plan for parameterized packages

Hi, zimoun skribis: >> To me the requirements for package parameters are: >> >> 1. it must be possible to discover them and choose them from the UI; >> >> 2. they must contain on-line internationalized documentation such that >> the UI can list a package’s parameters and their type; > >

Re: A plan for parameterized packages

Hi Pierre, Pierre Neidhardt skribis: > One of the biggest struggle we had when discussing it was figuring out > what to do about parameter propagation across dependencies. > > For instance, what if we want to build "all packages without X support"? > This means that the parameter must traverse a

Make mutiple packages from outputs (Was: A plan for parameterized packages)

zimoun writes: > Dear, > > On Sun, 15 Nov 2020 at 21:46, Danny Milosavljevic > wrote: > >> * Enable/disable building the documentation. I really don't need a 40 MiB >> manual stored onto a 16 MiB firmware flash chip. If that's better done as an >> extra output, fair enough. > > Related (I hop

Re: A plan for parameterized packages

On November 15, 2020, raingloom wrote: > Alpine already achieves an incredibly tiny install size by splitting > packages into many outputs. We could and should do the same. > As far as I know, they do not have parameterized packages. I definitely support more package-splitting and d

Re: A plan for parameterized packages

edibly tiny install size by splitting packages into many outputs. We could and should do the same. As far as I know, they do not have parameterized packages.

Re: A plan for parameterized packages

Dear, On Sun, 15 Nov 2020 at 21:46, Danny Milosavljevic wrote: > * Enable/disable building the documentation. I really don't need a 40 MiB > manual stored onto a 16 MiB firmware flash chip. If that's better done as an > extra output, fair enough. Related (I hope) is: build packages with seve

Re: A plan for parameterized packages

Hi Ludo, nice feature! On Sun, 15 Nov 2020 17:33:28 +0100 Ludovic Courtès wrote: > An important question: do we have examples of packages for which we’d > like to have parameters? For the embedded/flash rom side: * Enable/disable building the documentation. I really don't need a 40 MiB manua

Re: A plan for parameterized packages

An important question: do we have examples of packages for which we’d like to have parameters? I’d grepped for “inherit” and that yields a few potential candidates, but also maybe a few potential non-candidates. Would this be a good fit for them? I suppose Emacs would be an obvious candidate, w

Re: A plan for parameterized packages

Hi Pierre, On Sun, 15 Nov 2020 at 18:44, Pierre Neidhardt wrote: > For instance, what if we want to build "all packages without X support"? > This means that the parameter must traverse all inputs recursively if we > don't want to drag X indirectly. It means: add this new ’optionally’ to all th

Re: A plan for parameterized packages

Hi Lduo, On Sun, 15 Nov 2020 at 17:33, Ludovic Courtès wrote: > That said, this message is about a possible implementation of package > parameters, so here we go. :-) Cool! > To me the requirements for package parameters are: > > 1. it must be possible to discover them and choose them from

Re: A plan for parameterized packages

Fantastic! One of the biggest struggle we had when discussing it was figuring out what to do about parameter propagation across dependencies. For instance, what if we want to build "all packages without X support"? This means that the parameter must traverse all inputs recursively if we don't wan

Re: A plan for parameterized packages

y reasons, so it makes sense to have it disabled > by default. But I'd like to be able to enable it easily. > > WDYT? > > Nicolò > > [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39674 > > Ludovic Courtès writes: > >> Hello Guix! >> >> For some

Re: A plan for parameterized packages

c Courtès writes: > Hello Guix! > > For some time we’ve discussed ways to achieve “parameterized > packages”—packages where one can from the command line or from Scheme > configure optional build-time features, similar to Gentoo “USE flags”. > > I still have mixed feeling about this fe

A plan for parameterized packages

Hello Guix! For some time we’ve discussed ways to achieve “parameterized packages”—packages where one can from the command line or from Scheme configure optional build-time features, similar to Gentoo “USE flags”. I still have mixed feeling about this feature: on one hand it can bring much

Re: Parameterized packages

On Mon, 27 Jan 2020 at 12:51, Pierre Neidhardt wrote: > > zimoun writes: > > > Maybe I misread. :-) > > I am still convinced that it is not the correct design and instead be > > able to partially override the package definition seems more > > appropriate. > > If you have another design in mind th

Re: Parameterized packages

Hi Pierre, On Mon, 27 Jan 2020 at 11:13, Pierre Neidhardt wrote: > > zimoun writes: > > > Maybe I misread something and/or I misunderstand other thing but the > > symbols 'video-player' and 'python' need to be defined somewhere. And > > with this proposal adding the field 'parameters', this some

Re: Parameterized packages

Hi John, I believe the complexity will remain under control. "Flags" are not replacing Scheme: they are Scheme. Just like we have support for multiple outputs now. For newcomers, package parameters are not an issue since they are completely optional. You won't see them until you want them! Re

Re: Parameterized packages

Hi, On Fri, 24 Jan 2020 at 23:06, ison wrote: > My understanding of the global definitions they're talking about is that > they would just be meta objects, not global preferences. > For example (maybe it won't look like this, but just a guess): > Instead of passing the arguments "mpv" and "3.7"

Re: Parameterized packages

Hey all! I’ve been following very roughly. I have a couple issues with parameterized packages. > On Jan 22, 2020, at 4:24 AM, zimoun wrote: > > Well, I am wanting the same thing: be able to modify the 'arguments' > field but I am not convinced by the design you are prop

Re: Parameterized packages

On Wed, Jan 22, 2020 at 01:23:26PM +0100, zimoun wrote: > > > --8<---cut here---start->8--- > > > (define (make-you-get VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG) > > > (package > > > (inherit you-get > > > #:add-inputs > > > `(("PLAYER" ,VI

Re: Parameterized packages

Hi Pierre, On Wed, 22 Jan 2020 at 10:54, Pierre Neidhardt wrote: > zimoun writes: > > To me, a package is: > > "./configure && make && make check && make install" > > so I understand why tweak the flags used by "./configure", for example > > change "--with-vlc=" from the default 0 to the tuned

Re: Parameterized packages

zimoun writes: > I do not understand what you do mean by "does not compose". > > > To me, a package is: > "./configure && make && make check && make install" > so I understand why tweak the flags used by "./configure", for example > change "--with-vlc=" from the default 0 to the tuned 1. Or use a

Re: Parameterized packages

On Tue, 21 Jan 2020 at 14:13, Pierre Neidhardt wrote: > > zimoun writes: > > >> > --8<---cut here---start->8--- > >> > (define (make-me-a-package option1 option2) > >> > (package > >> > …)) > >> > --8<---cut here---end-

Re: Parameterized packages

zimoun writes: >> > --8<---cut here---start->8--- >> > (define (make-me-a-package option1 option2) >> > (package >> > …)) >> > --8<---cut here---end--->8--- >> >> The ellipsis is a bit vague here. What is this tryi

Re: Parameterized packages

Hi, Thank you for the explanations. On Mon, 20 Jan 2020 at 19:57, Pierre Neidhardt wrote: > > The solution of 2. and 3. seems to write, as Ludo mentioned: > > > > --8<---cut here---start->8--- > > (define (make-me-a-package option1 option2) > > (package >

Re: Parameterized packages

Hi, ison skribis: > Just a thought, but could this be achieved using Guile's parameterization > feature? > https://www.gnu.org/software/guile/manual/html_node/Parameters.html I don’t think so: these “parameters” (I like to write “SRFI-39 parameters” to avoid confusion, which refers to

Re: Parameterized packages

ison writes: > Just a thought, but could this be achieved using Guile's parameterization > feature? > https://www.gnu.org/software/guile/manual/html_node/Parameters.html > > Not sure which method will be best overall, but its something to consider > and might avoid the need to define a bunch of e

Re: Parameterized packages

On Mon, Jan 20, 2020 at 07:57:30PM +0100, Pierre Neidhardt wrote: > > The solution of 2. and 3. seems to write, as Ludo mentioned: > > > > --8<---cut here---start->8--- > > (define (make-me-a-package option1 option2) > > (package > > …)) > > --8<---

Re: Parameterized packages

zimoun writes: > What is the final aim to have parametrized packages? > What does it mean "parametrized"? Easy and composable customization of packages. > Does it mean extend the transformation options as Ludo described [2]. I think you forgot this reference. If you meant "like Ludo described

Re: Parameterized packages

On Mon, 20 Jan 2020 at 10:08, Pierre Neidhardt wrote: > > Ludovic Courtès writes: > > > I agree. ‘package-input-rewriting’ gives us almost what you want, with > > the limitation that implicit inputs are ignored (which is a good thing > > sometimes, and a problem in cases where you want to experi

Re: Parameterized packages

Hi Pierre, On Fri, 17 Jan 2020 at 17:56, Pierre Neidhardt wrote: > In this case, it's trivial to use parameters to influence which compiler > the build system will use. I am not sure that "trivial" is the correct word. ;-) > For gnu-build-system (with gcc, clang, etc.) we can probably do simi

Re: Parameterized packages

Hi Ludo, On Sun, 19 Jan 2020 at 21:34, Ludovic Courtès wrote: > > I feel something is lacking. > > I agree. ‘package-input-rewriting’ gives us almost what you want, with > the limitation that implicit inputs are ignored (which is a good thing > sometimes, and a problem in cases where you want t

Re: Parameterized packages

Ludovic Courtès writes: > I agree. ‘package-input-rewriting’ gives us almost what you want, with > the limitation that implicit inputs are ignored (which is a good thing > sometimes, and a problem in cases where you want to experiment with > toolchains, as you write). > > What we’d need is a var

Re: Parameterized packages

Hi, zimoun skribis: > To be clear, the seed (bootstrap) fixes how the compilers OCaml@4.01, > OCaml@4.07, OCaml@4.09, CPython@2.7, CPython@3.5, CPython@3.6, PyPy > (not yet in Guix), GCC@8, GCC@9, Clang@8, Clang@9, etc are compiled. > Then, it is difficult to use them to compile a package with o

Re: Parameterized packages

Hi, Nicolò Balzarotti skribis: > Hello! I've not followed the discussion with too much attention, so > forgive me if I'm plain wrong. > But, if I get this right, to me it seems we want something similar to > what nix is already doing. To me, what Nix is doing amounts to: (define (make-me-a-p

Re: Parameterized packages

Hi Zimoun! zimoun writes: > Well, it would ease comparison in the HPC world. :-) > > > It is not related to the "parametrized package" in the sense of flag > options. :-) > > And I do not know if it make sense. What do you think? I think you are making a lot of sense and yes, parameters should

Re: Parameterized packages

Hi! L p R n d n writes: > (define-modificator headless > `((xorg (modify-package xorg > ...)) Thanks for sharing, this is an interesting approach! But it may raise a major challenge. The point of parameters is that they must compose (e.g. h

Re: Parameterized packages

Hi Ricardo, Ricardo Wurmus writes: > I think this is a sensible approach, though it would require agreement > or at least coordination among package contributors about what > parameters to use. For example, one such parameter could be > “#:headless” to disable any graphical user interface or de

Re: Parameterized packages

Hi ison! ison writes: > Maybe the current discussion is trying too hard to emulate Gentoo's USE > flags and dependency graph concept (perhaps its my fault for bringing up > global flags). But that feels like introducing "side effects", and maybe the > whole idea should be treated more "functiona

Re: Parameterized packages

On Thu, 16 Jan 2020 at 20:06, ison wrote: > On Wed, Jan 15, 2020 at 02:54:25PM +0100, zimoun wrote: > > And what I was thinking is a mechanism to easily set some arguments to > > the build-system; for example changing the compiler toolchain (say > > replacing GCC by Clang/LLVM). > > > > Well, as

Re: Parameterized packages

Hello! Also followed the thread from a little far away. It's probably an awfull idea (I don't even know if it's possible) but throwing in different perspetives migh give birth to new ones so here I go. Instead of thinking in terms of use flags or parameterized packages maybe using

Re: Parameterized packages

Hello! I've not followed the discussion with too much attention, so forgive me if I'm plain wrong. But, if I get this right, to me it seems we want something similar to what nix is already doing. Taking handbrake[1] recipe as an example: there's the useGtk flag that can be passed to the package de

Re: Parameterized packages

ison writes: > Maybe the current discussion is trying too hard to emulate Gentoo's USE > flags and dependency graph concept (perhaps its my fault for bringing up > global flags). But that feels like introducing "side effects", and maybe the > whole idea should be treated more "functionally" in

Re: Parameterized packages

On Wed, Jan 15, 2020 at 02:54:25PM +0100, zimoun wrote: > Everything is doable with Guix. ;-) > However, it is not clear to me what is the best/easiest way to go. > For example, here [2] I give a try. > > [2] https://lists.gnu.org/archive/html/help-guix/2020-01/msg00087.html > > > And what I was

Re: Parameterized packages

On Wed, 15 Jan 2020 at 12:51, Pierre Neidhardt wrote: > > zimoun writes: > > > For example, be able to rebuild all the packages with GCC-8.3, or to > > install Python packages with Python 3.5 instead of the current default > > Python 3.7. > > I think this would tackle a different issue. The poin

Re: Parameterized packages

Hi Pierre, On Wed, 15 Jan 2020 at 10:40, Pierre Neidhardt wrote: > - The source. > - The explicit inputs. > - the implicit inputs. > - The build inputs. > - The build system inputs. > - Recursive inputs. > - ...? > > Which one should we expose? I don't know. If we want the system to > have som

Re: Parameterized packages

Hi Simon! You are making a good point: there are different levels of "accessibility" when it comes to inputs: - The source. - The explicit inputs. - the implicit inputs. - The build inputs. - The build system inputs. - Recursive inputs. - ...? Which one should we expose? I don't know. If we wa

Re: Parameterized packages

Hi Pierre, I do not not if it related. Currently, the option "--with-input" does not re-write the implicit inputs. Probably for good reasons. :-) For example, say I would like to have the version 3.4.3 of R (2017 old). This version is really old and had disappeared. Other said, it is older than

Re: Parameterized packages

Hi Ludo! Ludovic Courtès writes: > The way I see it, we’re still toying with the idea and its pros and > cons—discussions about CLI syntax can come later. ;-) Sure thing! > The added flexibility of package parameters is definitely nice, but > really, maintainability is a big concern. The exa

Re: Parameterized packages

Hello! The way I see it, we’re still toying with the idea and its pros and cons—discussions about CLI syntax can come later. ;-) The added flexibility of package parameters is definitely nice, but really, maintainability is a big concern. The example Tobias gave (a parameter to enable/disable X

Re: Parameterized packages

Pierre Neidhardt writes: > Any thought on this, anyone? Having used Gentoo for some years, I'm not sure a "global" parameter system is desirable. It could encourage enabling feature "foo", even for packages that have experimental or broken support for "foo". But I see how it could be useful to

Re: Parameterized packages

Hi! Bringing this topic back to life now that I'm starting working on this. 1. Everyone seems to agree that we need a dedicated field in the package declaration. For now, 3 names were proposed: - parameters - options - argument-overrides I find "argument-overrides" a bit too v

Re: Parameterized packages

On Fri, May 17, 2019 at 02:15:29PM -0400, Mark H Weaver wrote: > Also, at present, the current 'properties' field can be changed without > changing the derivation, and I think that's quite useful. It's nice to > be able to do things like increase the build timeouts on a core package, > for the sak

Re: Parameterized packages

Mark H Weaver writes: >> Ludovic Courtès wrote: >>> While thinking about <https://issues.guix.info/issue/35671> and >>> looking >>> for ways to allow users to install just the locales they need right >>> from >>> ‘guix package’, I rea

Re: Parameterized packages

Hi, Tobias Geerinckx-Rice writes: > Ludovic Courtès wrote: >> While thinking about <https://issues.guix.info/issue/35671> and >> looking >> for ways to allow users to install just the locales they need right >> from >> ‘guix package’, I realized tha

Re: Parameterized packages

Ludo', Ludovic Courtès wrote: While thinking about <https://issues.guix.info/issue/35671> and looking for ways to allow users to install just the locales they need right from ‘guix package’, I realized that “parameterized packages” are a low-hanging fruit Wow. Unexpected turn…

Parameterized packages

Hello Guix! While thinking about <https://issues.guix.info/issue/35671> and looking for ways to allow users to install just the locales they need right from ‘guix package’, I realized that “parameterized packages” are a low-hanging fruit (by “parameterized packages” I mean something kind