Re: "Parameterized Packages: The Project Completion Update"

Lost in communication I guess ;) Andy Tai aliandika: > no, not my effort. I just pointed out that report. credit to the > real author Sarthak Shah > I've actually met Sarthak on Matrix where he was talking about his work to our group. I used to stick around to hear what he had up his

Re: "Parameterized Packages: The Project Completion Update"

no, not my effort. I just pointed out that report. credit to the real author Sarthak Shah 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: > >

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 run out, but

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

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

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: 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 proposing because I > have

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"

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

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

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

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

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 > > …)) > >

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

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

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

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

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

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

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

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.

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

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

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 something that

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

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

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

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

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

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

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

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

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

Re: Parameterized packages

Mark H Weaver writes: >> Ludovic Courtès wrote: >>> While thinking about 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

Re: Parameterized packages

Hi, Tobias Geerinckx-Rice writes: > Ludovic Courtès wrote: >> While thinking about 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 >>

Re: Parameterized packages

Ludo', Ludovic Courtès wrote: While thinking about 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… I'm still