From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Bavier Subject: Re: [PATCH] gnu: Add Scikit-learn. Date: Thu, 26 Feb 2015 15:10:51 -0600 Message-ID: <34d78aa36c64669e2a26bc58b3fa9de6@openmailbox.org> References: <20150223175238.GA10579@debian.eduroam.u-bordeaux.fr> <20150225225215.GA13330@debian> <20150225225740.GA13495@debian> <87bnkg61js.fsf@gnu.org> <20150226175900.GA3835@debian> <648692e7170fada41ebd45ebe0724e42@openmailbox.org> <20150226204309.GA12643@debian> 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]:37951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR5hz-0007gn-4K for guix-devel@gnu.org; Thu, 26 Feb 2015 16:11:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YR5hu-0002se-Iq for guix-devel@gnu.org; Thu, 26 Feb 2015 16:10:59 -0500 In-Reply-To: <20150226204309.GA12643@debian> 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andreas Enge Cc: Guix-devel On 2015-02-26 14:43, Andreas Enge wrote: > On Thu, Feb 26, 2015 at 02:03:37PM -0600, Eric Bavier wrote: >> The issue in this case is that py2cairo and pycairo are actually >> different >> projects. I chose to use the name python2-py2cairo, to go with our >> "least >> divergence from upstream" method. > > Both seem to belong to the "pycairo" project: > http://cairographics.org/pycairo/ > which produces two different tarballs, one for Python 2 and one for > Python 3, > that are released with the same version. > > So I think it would make sense to in any case choose a common base > name, be it > "pycairo". That would also avoid the problems with dependencies that > Ricardo > faced. We recently discussed that we can choose the "project name" over > the "tarball name" in another example. Yes, that makes sense. > >> >that is, use the module name for >> >a package containing a single module. >> This could become error-prone. The packager needs to check the >> interface of >> the library before deciding on a package name? It might also not be >> future-proof, in the event that a project updates its public >> interface. > > Indeed, the new rule would require to have a look at the output of a > package > to count the number of modules... I copied it from the Perl case; are > things > different there, and each module is distributed in a separate tarball > for Perl? No, perl has what are called "distributions". Many distributions contain a single module and possibly submodules, but in many cases there are more than one module in a distribution. Our perl packages are named after the distribution. > I think the question of being future proof is not such a big problem, > we can > always modify package names (with a bit of work, of course). > > So you would suggest to always use the "project name" and not the > "module > name" for Python packages? Yes. -- `~Eric