From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Frederickson Subject: =?UTF-8?B?UmU6IOKAnEd1aXggUHJvZmlsZXMgaW4gUHJhY3RpY2XigJ0=?= Date: Fri, 25 Oct 2019 20:34:04 -0400 Message-ID: <84995292-3551-2323-15d9-6ade421d030f@terracrypt.net> References: <87r231rulr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:54240) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOA28-0005tS-61 for guix-devel@gnu.org; Fri, 25 Oct 2019 20:34:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOA26-0000nV-TO for guix-devel@gnu.org; Fri, 25 Oct 2019 20:34:20 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:45763) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iOA24-0000lM-NA for guix-devel@gnu.org; Fri, 25 Oct 2019 20:34:18 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 122EF58D for ; Fri, 25 Oct 2019 20:34:14 -0400 (EDT) Received: from [10.213.3.40] (unknown [172.104.2.4]) by mail.messagingengine.com (Postfix) with ESMTPA id 1C67AD60057 for ; Fri, 25 Oct 2019 20:34:13 -0400 (EDT) In-Reply-To: Content-Language: en-US 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: guix-devel@gnu.org On 10/25/19 12:36 PM, Thompson, David wrote > 'guix environment' is a very composable command, and it's not clear to > me how I would add the stuff I want onto it and it's even less clear > if it's a good idea. Probably not. So, I wonder if maybe a new > subcommand, say 'guix develop', could address this common development > use-case while allowing 'guix environment' to continue being the swiss > army knife that it is. Some simple naming conventions could make this > tool "just work." Running 'guix develop' would check for a profile > symlink with some canonical name, for example '.guix-develop-profile'. > If it exists, it applies the environment variables and spawns a > subshell. If it doesn't exist, it looks for a 'develop.scm' file > (canonical name TBD), builds the profile, symlinks it to > '.guix-develop-profile', and then does the prior steps. The tool > would provide a mechanism to update, etc. and it could even be > expanded later to spawn services like databases. I love this idea, though I'd like to expand upon that a bit. There's another tool in the Python world that does something similar called Pipenv. The gist of it is: Pipfile: analogous to a Guix manifest Pipfile.lock: analogous to a Guix manifest + channel spec (this file contains precisely specified dependency versions) ~/.local/share/virtualenvs/: Generated virtualenvs (analogous to a Guix profile, of course) You work with these as follows: $ pipenv install ^ creates a virtualenv with packages from Pipfile.lock (if it exists) otherwise creates a virtualenv with packages from Pipfile and (by default) creates Pipfile.lock $ pipenv lock ^ resolves dependencies for packages in Pipfile and (re)creates Pipfile.lock $ pipenv shell ^ spawns a subshell in the project's virtualenv It occurs to me that you could nicely replicate this behavior in Guix by doing much the same thing; have a convenience command that reads a manifest with a well-known filename, creates profiles in a well-known location, and generates a channel spec (probably the current version of Guix the first time it's run). The end result is that a user could clone a project with both a manifest and channel spec and end up in the same environment by just running 'guix develop'.