From mboxrd@z Thu Jan 1 00:00:00 1970 From: ison Subject: Re: Parameterized packages Date: Thu, 16 Jan 2020 12:06:44 -0700 Message-ID: <20200116190644.uytvzvypuvdwh2iq@n0> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:42037) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1isATg-0000tV-RO for guix-devel@gnu.org; Thu, 16 Jan 2020 14:06:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1isATZ-0001GY-Qm for guix-devel@gnu.org; Thu, 16 Jan 2020 14:06:48 -0500 Received: from mx1.cock.li ([185.10.68.5]:54855 helo=cock.li) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1isATZ-0001BS-93 for guix-devel@gnu.org; Thu, 16 Jan 2020 14:06:41 -0500 Content-Disposition: inline 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@gnu.org 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 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 I said, I do not know if it is related to "parametrized > packages" because I am not sure to understand the final aim for these > "parametrized packages". :-) 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 Guix. That is, simplify the problem to the mere concept of passing arguments to functions and nothing more. Take the headless server example: some parameter is passed to a package such as '("-X") That package would then be entirely responsible for what to do with them. If the package decides not to pass the same parameters to its inputs then the inputs are simply built without any parameters. This would have the benefit of not breaking any existing packages regardless of what parameters are sent to them. And packages can be modified by maintainers to accept parameters and pass them on to their inputs as the need arises over time (e.g. packages typically installed by headless servers can be modified to pass the "-X" flag on to certain inputs). Additionally if someone wanted to take the risk and _force_ all inputs to use the same flags then they can use a function similar to "package-input-rewriting" (there could be a "package-use-flags-rewriting"), so it becomes similar to how other types of transformations are currently handled in Guix. Ideally packages can still be made to allow all flags to "trickle down" to their dependencies without input-rewriting simply by passing all parameters into their inputs in the package definition, but the difference here is that we don't force it. That's something that can be approached over time, or not. The idea is to just let packages do it if they want to, and let the package maintainers filter the list of flags before passing on to inputs if they need to, and the whole thing becomes more predictable and functional. This also avoids the problem of which types of inputs to modify (normal inputs, native-inputs, etc) because then it's just up to the package maintainer.