From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 30 15:08:18 2017 Received: (at 25235) by debbugs.gnu.org; 30 Mar 2017 19:08:18 +0000 Received: from localhost ([127.0.0.1]:53205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ctfQg-0002rn-L8 for submit@debbugs.gnu.org; Thu, 30 Mar 2017 15:08:18 -0400 Received: from o116.p8.mailjet.com ([87.253.233.116]:56825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ctfQe-0002re-Lh for 25235@debbugs.gnu.org; Thu, 30 Mar 2017 15:08:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; q=dns/txt; d=bnc3.mailjet.com; i=arunisaac=3Dsystemreboot.net@bnc3.mailjet.com; s=mailjet; h=message-id:mime-version:from:to:subject:date:list-unsubscribe:in-reply-to: references:x-csa-complaints:x-mj-mid:content-type:content-transfer-encoding; bh=zYw9lCeJI0Hmm7eiau4pp9KnQds=; b=YHajnAA2KQzZRSl6jFcv/uju9ZcFUtjrNKdUEyJiTYIb89td5LzKPOTjf pLj7pa41EsJObO8XOqYmSlrdPzUPlyCeNM+yw/UB2NOEMgPq8hu4zyFlDJzS IAfvpqugd04/4CONUlowbjLHMaxCeN6N5f+mGisZbgEc9cMJS/s+8I= Message-Id: MIME-Version: 1.0 From: Arun Isaac To: 25235@debbugs.gnu.org Subject: Re: bug#25235: Wrapped python programs get native-inputs in PYTHONPATH Date: Fri, 31 Mar 2017 00:37:53 +0530 In-reply-to: <87o9wiwzn2.fsf@gnu.org> References: <87eg13birp.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <87y3zahf8t.fsf@gnu.org> <20161226182608.GA20609@jasmine> <716a63e7.AEQAIoR8aXkAAAAAAAAAAAOwyEEAAAACwQwAAAAAAAW9WABY25oY@mailjet.com> <87o9wiwzn2.fsf@gnu.org> X-CSA-Complaints: whitelist-complaints@eco.de X-MJ-Mid: AEMAIlnS11YAAAAAAAAAAAOwyEEAAAACwQwAAAAAAAW9WABY3VefENX27K-NTeG0Ib8F8zoFLAAFgUc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > “Build-side” modules, which typically live in (guix build …), should not > depend on “host-side” modules such as (guix packages). That’s because > if we did that, we’d effectively end up importing all of Guix on the > build side, but then we’d also have to serialize data structures such as > packages to pass them from one side to the other. (I hope this makes > sense to you, but if it doesn’t maybe the intro of > can > shed some light.) [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [87.253.233.116 listed in list.dnswl.org] 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Debbugs-Envelope-To: 25235 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > “Build-side” modules, which typically live in (guix build …), should not > depend on “host-side” modules such as (guix packages). That’s because > if we did that, we’d effectively end up importing all of Guix on the > build side, but then we’d also have to serialize data structures such as > packages to pass them from one side to the other. (I hope this makes > sense to you, but if it doesn’t maybe the intro of > can > shed some light.) [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [87.253.233.116 listed in list.dnswl.org] 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid > “Build-side” modules, which typically live in (guix build …), should not > depend on “host-side” modules such as (guix packages). That’s because > if we did that, we’d effectively end up importing all of Guix on the > build side, but then we’d also have to serialize data structures such as > packages to pass them from one side to the other. (I hope this makes > sense to you, but if it doesn’t maybe the intro of > can > shed some light.) It makes some sense, but I'll read up more. > So in short, we cannot use ‘package-name’ and > ‘package-transitive-target-inputs’ in this module. Ok. > (Time passes…) > > I wasn’t sure how to fix this bug myself so I gave it a try and ended up > with the patch below, but I haven’t tested in detail. (You’ll notice > (guix build-system python) is hard to work with because it doesn’t use > gexps yet.) > > How does it look? I'm travelling now. I'll get back on Monday and study this patch.