From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Hinsen Subject: Re: Profiles/manifests-related command line interface enhancements Date: Tue, 05 Nov 2019 17:05:08 +0100 Message-ID: References: <87mudrxvs8.fsf@ambrevar.xyz> <87mudd59ho.fsf@gnu.org> <877e4glyc3.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:50538) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iS1KZ-0000yB-5q for guix-devel@gnu.org; Tue, 05 Nov 2019 11:05:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iS1KU-0007ak-48 for guix-devel@gnu.org; Tue, 05 Nov 2019 11:05:19 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:54865) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iS1KT-0007YN-07 for guix-devel@gnu.org; Tue, 05 Nov 2019 11:05:14 -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.org@gnu.org Sender: "Guix-devel" To: zimoun Cc: Guix Devel Hi Simon, > I am not sure to see which feature is missing. My main point is that the future evolution of functionality (and user interfaces) in this space should take into account usage scenarii, rather than adding features in an ad-hoc fashion. I can of course share a manifest file by putting it in a public repository. But that isn't necessarily the best way. Take the typical example from Docker tutorials: bundling a Web server with some Web application and a database. It's easy to make a manifest file for collecting the required packages. But it would make more sense to me to have a module in a Guix channel that defines a parametrizable super-package for the Web application that has no source code of its own but various inputs and perhaps configuration files. Users can then install several Web apps bundled in this fashion, sharing the Web server. This kind of composition is not possible (currently) with manifest files. > From my point of view, ephemeral (environment) vs persistent (profile) > depends on use-case but at the end the only concern is: how to > populate them? And the only answer should be: declarative (manifest); > the ad-hoc (package -i) should not be the usual way but only a > quick&dirt test. I agree. So maybe each profile should have an associated manifest file, with "guix install" merely adding to it and the updating the profile. But then it would make sense for guix to manage manifest files in git repositories by default, to encourage good habits. >> This third dimension also >> raises the question of where the information (profiles, manifests, ...) >> are stored and managed (version control?), > > Profiles are managed by Guix, isn't it? Sure, but how exactly? Right now, a profile is a directory anywhere in the file system that Guix knows about. Recent discussions have proposed alternatives, such as keeping all of a user's profile in some directory defined by convention and referring to them by name. What's the better way to use as a default? I don't know, but I think we should discuss it rather than adding new sub-commands with different behavior and thus adding to the mess. > Manifests are managed by the user. And they does what they wants. ;-) True again, but again, is that the best way to do it? Cheers, Konrad.