From: Eric Bavier <ericbavier@openmailbox.org>
To: Andreas Enge <andreas@enge.fr>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: [PATCH] gnu: Add Scikit-learn.
Date: Thu, 26 Feb 2015 15:10:51 -0600 [thread overview]
Message-ID: <34d78aa36c64669e2a26bc58b3fa9de6@openmailbox.org> (raw)
In-Reply-To: <20150226204309.GA12643@debian>
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
next prev parent reply other threads:[~2015-02-26 21:11 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
2015-02-26 21:10 ` Eric Bavier [this message]
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34d78aa36c64669e2a26bc58b3fa9de6@openmailbox.org \
--to=ericbavier@openmailbox.org \
--cc=andreas@enge.fr \
--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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).