From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: Re: Parameterized packages Date: Wed, 22 Jan 2020 10:54:46 +0100 Message-ID: <87zhefq0ih.fsf@ambrevar.xyz> References: <8736ldq74z.fsf@netris.org> <20190719202906.lbanx5puk7t6q4cr@cf0> <87a7753boq.fsf@ambrevar.xyz> <87h813wah0.fsf@gnu.org> <87v9piut40.fsf@ambrevar.xyz> <87o8v5ukgb.fsf@ambrevar.xyz> <87d0blhr9s.fsf@ambrevar.xyz> <20200116190644.uytvzvypuvdwh2iq@n0> <87d0bfrxr1.fsf@gnu.org> <87tv4qjy06.fsf@ambrevar.xyz> <875zh6rm5h.fsf@ambrevar.xyz> <87lfq1q7ea.fsf@ambrevar.xyz> 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]:54648) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuCip-0004uH-Jh for guix-devel@gnu.org; Wed, 22 Jan 2020 04:54:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuCio-0007d8-48 for guix-devel@gnu.org; Wed, 22 Jan 2020 04:54:51 -0500 In-Reply-To: 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-mx.org@gnu.org Sender: "Guix-devel" To: zimoun Cc: Guix Devel --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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=3D" from the default 0 to the tuned 1. Or use another > compiling toolchain. > I understand also these flags could require different inputs. If we reuse your example, a package may very well have --with-vlc and =2D-with-mpv. Those flags conflict, so the package definition must know about the corresponding "package parameters" at the same time to raise the appropriate error (or choose The Right Option automatically). Instead, if you'd inherit you'd always overwrite the changes without the user noticing. This removes a lot of control. > --8<---------------cut here---------------start------------->8--- > (define (make-you-get VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG) > (package > (inherit you-get > #:add-inputs > `(("PLAYER" ,VIDEO-PLAYER)) > ,@(IF WITH-FFMPEG) > ;; FOR MULTI-PART AND >=3D1080P VIDEOS > `("FFMPEG" ,FFMPEG) > #:replace-arguments ... > #:add-phase ... > '()))) > > (define-public you-get-vlc (make-you-get 'vlc)) > --8<---------------cut here---------------end--------------->8--- > > > Something like that. And everything is more controlled, What you propose here is essentially the same as what I propose, the difference is that you wrapped it around `make-you-get` instead of declaring the parameters inside as a field. > i.e., no mess with global parameters. I think there is a misunderstanding, there is no "mess with global parameters". Tobias suggestion was to declare the parameters (name, doc and type) globally, just like we declare record globally. > What you want to do is: add/remove/replace inputs/arguments so > #:add-inputs, #:remove-native-inputs, etc. Not just that, that's the point: we want the possibility to modify anything, in particular what's inside #:arguments. > Hum? but months later your system is broken... so I am not convinced > it is powerful. :-) > > It is broken because composing complex system is an hard task. Typing > helps a bit to detect error at compile time (in this case at building > package time) but run-time errors will still remain and it will be > hard time to find them. Why would it be broken after months? Packagers do the work once and it works. Of course the package parameters will have to be tested on update of the package definition. From the user's perspective, the worst case scenario is that a formerly support parameter goes unsupported for a given package, in which case we show a warning. What do you think? =2D-=20 Pierre Neidhardt https://ambrevar.xyz/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl4oG+YACgkQm9z0l6S7 zH8Xdgf8DJfhPHanJpWlTDM6ee3PUiimV97gsqtmzntU2H66jTtOpkqMnWlZetxd crk1x3XNisO6ud4MNxBqGATPJTW5jUUriv2dXLs/Tm8ozwOr8Qg+r7zlYW4X/70B Lr4KgM9ThXZ9xiw9mpMijFuPJRwYs79jxkDobFZ7i5OmxlbvJTZzfqdxk/vILW4x xkML6AnVNxlJZFQnCqbC91U03+Ik1d8Wjf4v1jMPe2dtfw4+BCfK0scv3BP0ysXa 5e62MkCSm28jws7Pt4ZHESS1m00lyB7z6G3vbgX2GFEK3jo7z+eISqafobV/Au1i 8Bp6wXZ1NzEvuYwhh3HerMOMz3W14Q== =7uBs -----END PGP SIGNATURE----- --=-=-=--