From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id WLgiMTnQql8ucAAA0tVLHw (envelope-from ) for ; Tue, 10 Nov 2020 17:39:05 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 6DcNLTnQql8RGAAAbx9fmQ (envelope-from ) for ; Tue, 10 Nov 2020 17:39:05 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 89B5F940509 for ; Tue, 10 Nov 2020 17:39:05 +0000 (UTC) Received: from localhost ([::1]:44260 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcXbk-0002wh-C5 for larch@yhetil.org; Tue, 10 Nov 2020 12:39:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56186) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcXbB-0002uZ-89 for guix-devel@gnu.org; Tue, 10 Nov 2020 12:38:29 -0500 Received: from dustycloud.org ([50.116.34.160]:49828) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcXb9-0001jI-5n for guix-devel@gnu.org; Tue, 10 Nov 2020 12:38:28 -0500 Received: from twig (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 6512826655; Tue, 10 Nov 2020 12:38:01 -0500 (EST) References: <87ft6c1ypz.fsf@dustycloud.org> <865z77smyg.fsf@gmail.com> <87a6wizuic.fsf@dustycloud.org> <86blg6xncq.fsf@gmail.com> <87a6vqxm3m.fsf@bendersteed.tech> <87imaem9dd.fsf@dustycloud.org> <865z6djtze.fsf@gmail.com> User-agent: mu4e 1.4.13; emacs 27.1 From: Christopher Lemmer Webber To: "Bonface M. K." Subject: Re: Racket packages / build system In-reply-to: <865z6djtze.fsf@gmail.com> Date: Tue, 10 Nov 2020 12:37:29 -0500 Message-ID: <87r1p1f6zq.fsf@dustycloud.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=50.116.34.160; envelope-from=cwebber@dustycloud.org; helo=dustycloud.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/10 12:38:25 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, Dimos Dimakakos , Pjotr Prins Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: aZF7peoriZIj Bonface M. K. writes: > Christopher Lemmer Webber > writes: > >> Dimos Dimakakos writes: >> >>> Bonface M. K. writes: >>> >>>> To simply put it, AFAIU updating a package would >>>> require racket to update it's references(either >>>> links, and other references that I won't go into), >>>> hence creating some form of "global state"; >>>> thereby if you use raco, every package updated >>>> would lead to some update with racket's search >>>> paths or dirs somewhere. Any ideas to overcome >>>> this wall? (or anything I've got wrong somewhere?) >>> >>> This was one of the main problems that I also encountered when working >>> on this. racket2nix solves this by generating a temporary environment >>> (by coping most of the racket folders and the deps needed as writable >>> folders) where it installs with raco and then tries to update the global >>> state of racket. >>> >>> To be honest this solution is kinda hacky and also slow, but I couldn't >>> think of another one at the time I tried to work on the issue. It's a >>> reality that the racket install system is quite stateful and also many >>> operations seem to try to touch files. Installing with raco for example >>> will try to recompile the dependencies of the new package and other such >>> examples. >>> >>> Anyway, I hope you can find a way to move this forward! >> >> I wonder if it would be a good idea to copy many of the points from this >> email and the parent to racket-users or racket-dev and see if someone >> more familiar with the structure of the system can provide guidance from >> there? >> > > This is a good idea IMHO. I'll go ahead and do > this. Perhaps there's something more important > we've missed or aren't seeing. > >> If we have to go the racket2nix route, it would be better than nothing I >> guess. >> > > Yeah. I'm considering going though this route as a > last resort. I don't understand the nix DSL > syntax(though it reads alot like Haskell!). > >> Another possible route: don't use the Racket installer tooling. >> Instead, read the info.rkt file of the package to understand what raco >> *probably would* do, and then do it in a more Guix way instead. >> >> What do you think of that route? > > I've considered doing this... studying raco's source and seeing how it > actually does and sets up things. I'd rather do this than the above, > but it would take more time and would lead to alot more boiler plate I > think... I'm not entirely sure about how to work around the global > state though... Regarding the boilerplate, not sure it needs to from a package-definitions perspective... if the info.rkt can be read in the general case, this could be the racket-build-system that does most of the work (probably even by reading the very same info.rkt) rather than it being output'ed from an importer definition. > First, let's consult with the racket-devel and racket-user ML and see > what those communities have to suggest... Yes, good idea.