From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: Re: Parameterized packages Date: Thu, 02 Jan 2020 20:23:01 +0100 Message-ID: <87a7753boq.fsf@ambrevar.xyz> References: <87woitz1xx.fsf@gnu.org> <87o945vze5.fsf@nckx> <8736ldq74z.fsf@netris.org> <20190719202906.lbanx5puk7t6q4cr@cf0> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:51541) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1in63n-0000y9-PI for guix-devel@gnu.org; Thu, 02 Jan 2020 14:23:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1in63m-00038n-4d for guix-devel@gnu.org; Thu, 02 Jan 2020 14:23:07 -0500 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:37707) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1in63l-00032Q-QP for guix-devel@gnu.org; Thu, 02 Jan 2020 14:23:06 -0500 In-Reply-To: <20190719202906.lbanx5puk7t6q4cr@cf0> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: ison , Mark H Weaver Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 verbose :p I'll go with "parameters" for now since it's the title of this thread. 2. As Tobias and Ison suggested, we need to centralize the declaration of parameters, so that we can list them and centralize metadata like the description & types. Any suggestion on how to implement this in practic= e? Where do we store them? How? 3. From Ludo's comment: > =E2=80=A2 We=E2=80=99d need to store more info in manifest entries so th= at > transformation options are preserved upon =E2=80=98guix upgrade=E2=80= =99. > ... > =E2=80=A2 We might want to make the CLI option less verbose too, but how? We'd also need a way to specify the parameters in the manifest specs and = from command line. Now we have "@" and ":" for versions and outputs respectively. What about parentheses? E.g. "foo@2.0(:locale fr_FR.UTF-8 :audio pulseaudio :gui X)" I think a plist like above would be less verbose than an alist. To apply parameters to the rest of the command line, we could also do: guix install --with-parameters=3D"(:locale ...)" package-foo package-bar 4. From Ludo's comment: > =E2=80=A2 We might need to expose the package parameters somehow, so t= hat if > one types =E2=80=98--with-argument=3Dfoobar=3Dbaz=E2=80=99, they get = a correct error > message saying that =E2=80=9Cfoobar=E2=80=9D is not a known parameter. I think we should only display a warning so that we can emulate global U= SE flags as Ison suggested. 5. Global parameter storage When using "guix install" it can be convenient not to have to repeat the parameter specification. So it'd be nice to store it somewhere. What a= bout a file in ~/.config/guix/parameters.scm with something like (parameters :locale fr_FR.UTF-8 :audio pulseaudio ...) ? 6. Leverage build systems to automate parameterization when possible. Some build systems use well-known flags. For instance, for the gnu-build-system if the user sets the parameter "(:audio pulseaudio)" we= could automatically pass --enable-pulseaudio to the "configure" flags, even for packages that didn't specify their own well-known parameters. It would be nice if build systems had a way to report if a flag is suppo= rted or not. Any clue? To implement this, we could do the following: (define-parameter audio "Some description" (types ...) (argument (lambda (pkg) (match (package-build-system pkg) (gnu-build-system (add-to-configure-flags "--enable-pulseaudio")) (cmake-build-system (...)))))) 7. Dependency management. Also known as the USE flag nightmare among Gentoo users... This is where hell breaks loose! :p The problem: the user wants to specify a parameter to use globally where= it applies, on all installed packages and all their inputs, recursively. For instance, use guile-2.2.4 instead of guile for all guile libraries, = or use pulseaudio everywhere, including in dependencies that are not explic= itly installed to the user profile. The obstacle: A package may require inputs with a specific parameter. For instance, BAR depends on a FOO package built with ":audio pulseaudio". What happens if the user seta ":audio alsa" globally and installs BAR? BAR needs to specify explicitly that its FOO input requires pulseaudio. Otherwise BAR would fail to build. To specify that a package input depends on a specific parameter, we could extend the syntax of the (inputs ...) and (native-inputs ...) fields lik= e so: (input `(("foo" ,foo "(:audio pulseaudio)"))) A bigger problem is that the parameter compatibility issue is combinator= ial: "Which parameter combination does BAR support?" It's hard to know it in advance. Any idea how to tackle this? The easy way around this is to not propagate the global parameters by default, but this seriously limits the usefulness of global parameters. Maybe a better workaround would be to automatically fall back to the def= ault value of all parameters when a build fails. =20=20=20 Cheers! =2D-=20 Pierre Neidhardt https://ambrevar.xyz/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl4OQxUACgkQm9z0l6S7 zH88Tgf/Yq4JVV0L6B6lbxkpQxPQEYwuFxXF/b5j9wcQN2p+ulVUMdxSD+LziAQN aj3BENAJ6VOUOwug4yObtFxWZ3TR62C0Su0bpNk3+nUzUgGjCBOxoq1FWGvFYWxF SXdrWKyWSyQtghu60mQu4xXEV6+7LhS8zbd9RBdoNuuS4VChEl/+eElbLb5mtc7E 0rbXB1ckupQGF27Hjb7dnrEXONDLV64+A6WHdv1kkYb7ihX1b9vd/ZOAxKeowFDD hlaYJfi/vhyXwvDzfUZL9R0RmJ1H1z5V95DthwSalwXinSSyIdJFIeyAbi0EM4A6 f9EYHKOmfLapdGQJDAfHv7U/JefcTg== =Ns8I -----END PGP SIGNATURE----- --=-=-=--