From: Andreas Enge <andreas@enge.fr>
To: Eric Bavier <ericbavier@openmailbox.org>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: [PATCH] gnu: Add Scikit-learn.
Date: Thu, 26 Feb 2015 21:43:09 +0100 [thread overview]
Message-ID: <20150226204309.GA12643@debian> (raw)
In-Reply-To: <648692e7170fada41ebd45ebe0724e42@openmailbox.org>
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.
> >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?
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?
Andreas
next prev parent reply other threads:[~2015-02-26 20:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 16:24 [PATCH] gnu: Add Scikit-learn Ricardo Wurmus
2015-02-23 17:17 ` Ricardo Wurmus
2015-02-23 17:36 ` Andreas Enge
2015-02-26 11:28 ` Ricardo Wurmus
2015-02-26 20:44 ` Andreas Enge
2015-02-23 17:52 ` Andreas Enge
2015-02-25 22:52 ` Andreas Enge
2015-02-25 22:57 ` Andreas Enge
2015-02-26 17:11 ` Ludovic Courtès
2015-02-26 17:59 ` Andreas Enge
2015-02-26 18:20 ` Ludovic Courtès
2015-02-26 18:23 ` Andreas Enge
2015-02-26 20:03 ` Eric Bavier
2015-02-26 20:43 ` Andreas Enge [this message]
2015-02-26 21:10 ` Eric Bavier
2015-02-27 9:41 ` Andreas Enge
2015-02-27 22:48 ` Andreas Enge
2015-02-27 23:53 ` Andreas Enge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150226204309.GA12643@debian \
--to=andreas@enge.fr \
--cc=ericbavier@openmailbox.org \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.