From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id yACRBfTSpWT0EgAASxT56A (envelope-from ) for ; Wed, 05 Jul 2023 22:30:44 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id APN1BfTSpWSAgAAA9RJhRA (envelope-from ) for ; Wed, 05 Jul 2023 22:30:44 +0200 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 B74411EF46 for ; Wed, 5 Jul 2023 22:30:43 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=Fnqy2iGr; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1688589043; a=rsa-sha256; cv=none; b=CjB92aEkBcaWN4b5oL6ajUiGjgyH89Tn/lgGCZw6lHXD5YicJOCAMmGXvADTA/WMvbd7sO Auf/n76fPD2RJUgQAxxPHoffQ4bJQfN9mGBuSjxB+I7Jk273bX3XUOmnqdJ2NU0S612a/j +JeGPmj9UJIWue5o4YahWB7ftpTyppH3Cy8IehEA9Tboc5RdoFzOFGHfSoXWJfwWOgMvZx cCdRpIWPfk4cnUFWGuV8OY+bjkW6ipWiykrK0G8dao0jfKhfVP0noLId9rC3GldTmymYY1 H9FVOfztK54OD8CtZgEHIIZGSBa/TEOHNYKHRVMq3AXnHxwfRL5/Y1qr/1NgMw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=Fnqy2iGr; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1688589043; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=60iU1IB1HzP7PAlZ1WSY0TX2oTL4fZk6DbdiI1jM8LA=; b=o4kE29lY7AC10eJ0jJF+l7angAtwVTwrclecPTMeuECXU5Nsmj4a4sz0isOFbcztiP1tAF +TD0TDarqX33c//dcZUDI8+vdHrqWvuAE9Y4kQWCuTCmRU26HNcEpMoU3WXqVO5ox47V4c OjJa9CaDEMgaAh8npzQOj8NYorb9HH/kHAkU/DMhHxkP/SQ8r90I+3vTDrNOcOLYzjIc+y IPMA673TCab0JuLeockOlTG2MB8/9QKdd2BpDnIbfIs8SPU+Q52yz7R35XjIH6cx6u/Njq K3Eemk1AK8Bcu/UAhyDXEMwy8/urZtNQOPFYGDL3YZUKLkI2XyZUMm4daxo2JQ== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qH98g-0002Sk-UE; Wed, 05 Jul 2023 16:30:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qH98b-0002SB-SY for guix-devel@gnu.org; Wed, 05 Jul 2023 16:30:10 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qH98Y-0002zK-Ct for guix-devel@gnu.org; Wed, 05 Jul 2023 16:30:08 -0400 Date: Wed, 05 Jul 2023 20:29:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1688589002; x=1688848202; bh=60iU1IB1HzP7PAlZ1WSY0TX2oTL4fZk6DbdiI1jM8LA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Fnqy2iGr1BFlrXlyoj4mJn/3UNF6p39am+PTWLoFAOFDTFwEKXi/slYP6ONP0qArF BO6Pk4/27tP9oQvrarv+6XxJMLhM4SbFpzu5ciHiRqQB5CWf+JQtkAa7YvDBHtGiEx aAzMFXdzf79hsXGRoseIWiZuvfvA0v4VIWfAi8jpbGKsiz01SV3H2mTWU/fDE74f8X glizHy0kBcaUXft0+bHZFYa8oHSDtu75qPiTI7zWG60tEJPMGD9ckPzsvjXAVXilzQ 6Wp1jOk6qvKrJR8b+cdmRSLy9k23iW7X6veOJ7ujRq/skffMVgE2MLmkWLIaRX8Woj VTq18+aZ4pUSQ== To: Maxim Cournoyer From: John Kehayias Cc: Wojtek Kosior , =?utf-8?B?5a6L5paH5q2m?= , edk@beaver-labs.com, guix-devel@gnu.org Subject: Re: Guix's python has pip's user dir in its loadpath Message-ID: <87cz16kspd.fsf@protonmail.com> In-Reply-To: <871qhr1v6y.fsf@gmail.com> References: <87edmey1wg.fsf@rdklein.fr> <877crma7qe.fsf@envs.net> <87edls1fyk.fsf@gmail.com> <20230701133257.6ada1e94.koszko@koszko.org> <871qhr1v6y.fsf@gmail.com> Feedback-ID: 7805494:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.16; envelope-from=john.kehayias@protonmail.com; helo=mail-4316.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list 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+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -4.98 X-Migadu-Queue-Id: B74411EF46 X-Spam-Score: -4.98 X-TUID: eUfNcmukY9vD Hi, On Sat, Jul 01, 2023 at 11:57 AM, Maxim Cournoyer wrote: > Hi, > > Wojtek Kosior writes: > >> The precedence of local, pip-installed Python libraries over Guix ones >> has already been a source of bugs. And these can be hard to diagnose. > >> I imagine an optimal solution would be to configure this behavior on >> per-package basis. The vast majority of applications does not need to >> load local libraries. There are just a few exceptions like >> `python-virtualenv`. >> >> Once I did write a package definition that deliberately disabled user >> site dir package loading. I used code similar to what's below. >> >>> (modify-phases %standard-phases >>> (add-after 'wrap 'prevent-local-package-interference >>> (lambda* (#:key outputs #:allow-other-keys) >>> (substitute* (string-append (assoc-ref outputs "out") >>> "/bin/") >>> (("^#!/.*$" shabang) >>> (string-append shabang >>> "export PYTHONNOUSERSITE=3D1\n")))))) > > That is indeed a simple thing we could do to harden Python binaries from > picking up user pip-installed dependencies potentially causing > problems. I would welcome such a patch. > Perhaps, but if this is expected (and known) upstream behavior, I'm wary of deviating from these expectations. This general area does seem tricky and no simple best answer I guess. >> Of course, it makes no sense to add such snippet to all definitions. >> Instead, we could modify python-build-system to allow doing a similar >> thing based on a flag passed in package's `(arguments)`. > > I think it need not be made configurable but just applied > indiscriminately to the wrap phase used in the python-build-system. And this is part of the same question then, we should try to be consistent, yes. I don't see a clear right path, but I haven't thought much about this area. I think it comes down to a current issue/limitation/quirk of Python from upstream and packaging for our distro puts us in between what comes from them and how to take care of our users. But we'll be rebuilding the Python world anyway, so now is a chance to try out some changes like that, though maybe it is a bit much with what we are trying already. See John