Re: [PATCH] gnu: Add Scikit-learn.

[Eric Bavier]

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