From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Bavier Subject: Re: [PATCH 02/12] import: utils: Symbols from 'license->symbol' have a license: prefix. Date: Fri, 16 Sep 2016 12:02:43 -0500 Message-ID: References: <20160805183730.19049-2-david@craven.ch> <87k2f2ognn.fsf@elephly.net> <20160830140748.085c3492@openmailbox.org> <20160916000338.44cc4d03@openmailbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkwXU-0007Lj-U6 for guix-devel@gnu.org; Fri, 16 Sep 2016 13:03:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkwXP-0005lR-T3 for guix-devel@gnu.org; Fri, 16 Sep 2016 13:02:59 -0400 Received: from smtp7.openmailbox.org ([62.4.1.41]:34914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkwXP-0005kI-L0 for guix-devel@gnu.org; Fri, 16 Sep 2016 13:02:55 -0400 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: David Craven Cc: guix-devel On 2016-09-16 10:47, David Craven wrote: >> AFAIK we haven't established module-level global symbol prefixing as >> best >> practice. In gnu/packages/perl.scm it's unnecessary. > > It's a fact that if we don't establish a best practice, the (generic) > importer code won't fit all importer implementations. Maybe you could > have been a bit more vocal about this at the time. Constructively - > what do you expect me to do about this? I'll correct myself now in my assertion that this change broke `guix import cpan`, which uses its own string->license procedure. Indeed, apparently the only user of the string->license and license->symbol in (guix import utils) is the pypi importer. My suggestion would be to move those procedures back into (guix import pypi). I don't think they are as generic as their inclusion in (guix import utils) might suggest. The strings they accept are specific to pypi. Perhaps what might also be done is to clarify in the documentation that the importers are not meant to be "dumpers": their output is not intended to be dumped directly into package modules and pushed upstream, and that editing will most likely need to take place. Maybe adding a 'guix-import' command to guix.el could improve on this situation in particular, by using geiser to detect proper symbol prefixes, since it could have an understanding of what module the imported package is destined for. -- `~Eric