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

[Eric Bavier <ericbavier@openmailbox.org>]

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