Perl modules

Perl modules

[Andreas Enge]

Hello,

it looks like I have stumbled upon an enormous dependency tree:

For kdelibs, I would like soprano;
for soprano, I would like redland;
for redland, I need rasqal;
for some tests of rasqal to work, I need perl-xml-dom;
for perl-xml-dom, I need libwww-perl;
for libwww-perl, I need a lot of packages:
Warning: prerequisite Encode::Locale 0 not found.
Warning: prerequisite File::Listing 6 not found.
Warning: prerequisite HTML::Entities 0 not found.
Warning: prerequisite HTML::HeadParser 0 not found.
Warning: prerequisite HTTP::Cookies 6 not found.
Warning: prerequisite HTTP::Daemon 6 not found.
Warning: prerequisite HTTP::Date 6 not found.
Warning: prerequisite HTTP::Negotiate 6 not found.
Warning: prerequisite HTTP::Request 6 not found.
Warning: prerequisite HTTP::Request::Common 6 not found.
Warning: prerequisite HTTP::Response 6 not found.
Warning: prerequisite HTTP::Status 6 not found.
Warning: prerequisite LWP::MediaTypes 6 not found.
Warning: prerequisite Net::HTTP 6.04 not found.
Warning: prerequisite URI 1.10 not found.
Warning: prerequisite URI::Escape 0 not found.
Warning: prerequisite WWW::RobotRules 6 not found.

This leads me to the question: How should the packages containing perl
modules be named, and in which files should they be defined?

So far, there are the following packages in xml.scm:
perl-xml-parser containing XML-Parser
perl-xml-parser-perlsax containing libxml-perl
perl-xml-simple containing XML-Simple

The second one is definitely a misnomer; I was looking for
XML::Parser::PerlSAX, and a search led me to the documentation page
  http://search.cpan.org/~kmacleod/libxml-perl-0.08/lib/XML/Parser/PerlSAX.pm
which is just one of the modules of libxml-perl
  http://search.cpan.org/~kmacleod/libxml-perl-0.08/

If we follow our standard naming scheme, then the packages should be called
xml-parser, libxml-perl and xml-simple. Notice that two of them do not
contain the word "perl". Should we add "perl" in front then, similarly to
what we do with python modules? How about libxml-perl? Do we keep it as such,
or should we then call it perl-libxml-perl for consistency?

Concerning the files, maybe all perl modules should go into perl.scm?

Your opinions are welcome.

Andreas

Re: Perl modules

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> it looks like I have stumbled upon an enormous dependency tree:
>
> For kdelibs, I would like soprano;
> for soprano, I would like redland;
> for redland, I need rasqal;
> for some tests of rasqal to work, I need perl-xml-dom;
> for perl-xml-dom, I need libwww-perl;
> for libwww-perl, I need a lot of packages:

Ouch.  :-)

> This leads me to the question: How should the packages containing perl
> modules be named, and in which files should they be defined?
>
> So far, there are the following packages in xml.scm:
> perl-xml-parser containing XML-Parser
> perl-xml-parser-perlsax containing libxml-perl
> perl-xml-simple containing XML-Simple
>
> The second one is definitely a misnomer; I was looking for
> XML::Parser::PerlSAX, and a search led me to the documentation page
>   http://search.cpan.org/~kmacleod/libxml-perl-0.08/lib/XML/Parser/PerlSAX.pm
> which is just one of the modules of libxml-perl
>   http://search.cpan.org/~kmacleod/libxml-perl-0.08/
>
> If we follow our standard naming scheme, then the packages should be called
> xml-parser, libxml-perl and xml-simple. Notice that two of them do not
> contain the word "perl". Should we add "perl" in front then, similarly to
> what we do with python modules? How about libxml-perl? Do we keep it as such,
> or should we then call it perl-libxml-perl for consistency?

I would add the ‘perl-’ prefix, unless the package stands alone (for
instance, Hydra would be called ‘hydra’, not ‘perl-hydra’.)

For the rest of the name, I would take the Perl module name.  So
‘XML::Parser’ leads to ‘perl-xml-parser’, etc.

In cases where there’s not a single module tree root, I would stick to
the upstream name, removing any redundant ‘perl’ in the name.  So
‘libxml-perl’ (which provides modules under XML::, Data::Grove, etc.)
would lead to ‘perl-libxml’.

How does that sound?

> Concerning the files, maybe all perl modules should go into perl.scm?

I don’t think so.  For instance, I think it’s OK to have perl-xml-* in
xml.scm, esp. because they are also used by ‘intltool’ for instance.
I’d use perl.scm for any Perl-specific library that doesn’t have a
better home (yeah, that’s very informal...)

WDYT?

Ludo’.

Re: Perl modules

[Andreas Enge]

On Fri, Dec 06, 2013 at 11:56:17PM +0100, Ludovic Courtès wrote:
> I would add the ‘perl-’ prefix, unless the package stands alone (for
> instance, Hydra would be called ‘hydra’, not ‘perl-hydra’.)

Yes, that would be as for python.

> For the rest of the name, I would take the Perl module name.  So
> ‘XML::Parser’ leads to ‘perl-xml-parser’, etc.
> 
> In cases where there’s not a single module tree root, I would stick to
> the upstream name, removing any redundant ‘perl’ in the name.  So
> ‘libxml-perl’ (which provides modules under XML::, Data::Grove, etc.)
> would lead to ‘perl-libxml’.
> 
> How does that sound?

All very reasonable. Let us go for this (and I should add a section to the
packaging guidelines later on).

Andreas

Re: Perl modules

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On Sat, Dec 07, 2013 at 09:24:42PM +0100, Andreas Enge wrote:
> All very reasonable. Let us go for this (and I should add a section to the
> packaging guidelines later on).

Months later, here is a proposed patch in British English. Do we have a rule
on which spelling to use? British is what I learnt at school.
(I feel like starting a bikeshed discussion ;-).)

Andreas


[-- Attachment #2: 0001-doc-Add-a-section-on-perl-modules-in-the-packaging-g.patch --]
[-- Type: text/plain, Size: 2200 bytes --]

From 97a3ac573edcb3046ee9655497a97bdf750090ee Mon Sep 17 00:00:00 2001
From: Andreas Enge <andreas@enge.fr>
Date: Sun, 11 May 2014 10:43:51 +0200
Subject: [PATCH] doc: Add a section on perl modules in the packaging
 guidelines.

* doc/guix.texi (Perl modules): New section explaining the naming of perl
    modules.
---
 doc/guix.texi | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 2aacf5d..de50ae5 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2751,6 +2751,7 @@ needed is to review and apply the patch.
 * Package Naming::       What's in a name?
 * Version Numbers::      When the name is not enough.
 * Python Modules::       Taming the snake.
+* Perl Modules::         Little pearls.
 @end menu
 
 @node Software Freedom
@@ -2796,8 +2797,8 @@ Both are usually the same and correspond to the lowercase conversion of the
 project name chosen upstream.  For instance, the GNUnet project is packaged
 as @code{gnunet}.  We do not add @code{lib} prefixes for library packages,
 unless these are already part of the official project name.  But see
-@ref{Python Modules} for special rules concerning modules for
-the Python language.
+@ref{Python Modules} and @ref{Perl Modules} for special rules concerning
+modules for the Python and Perl languages.
 
 
 @node Version Numbers
@@ -2859,6 +2860,19 @@ for instance, the module python-dateutil is packaged under the names
 @code{python-dateutil} and @code{python2-dateutil}.
 
 
+@node Perl Modules
+@subsection Perl Modules
+
+Perl programs standing for themselves are named as any other package,
+using the lowercase upstream name.
+For perl packages containing a single class, we use the lowercase class name,
+replace all occurrences of @code{::} by dashes and prepend the prefix
+@code{perl-}.
+So the class @code{XML::Parser} becomes @code{perl-xml-parser}.
+Modules containing several classes keep their lowercase upstream name and
+are also prepended by @code{perl-}. Such modules tend to have the word
+@code{perl} somewhere in their name, which gets dropped in favour of the
+prefix. For instance, @code{libwww-perl} becomes @code{perl-libwww}.
 
 
 
-- 
1.8.4

Re: Perl modules

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

On Sun, May 11, 2014 at 10:56:38AM +0200, Andreas Enge wrote:
     On Sat, Dec 07, 2013 at 09:24:42PM +0100, Andreas Enge wrote:
     > All very reasonable. Let us go for this (and I should add a section to the
     > packaging guidelines later on).
     
     Months later, here is a proposed patch in British English. Do we have a rule
     on which spelling to use? British is what I learnt at school.
     
Ahh, but which variant of British English? Oxford or Cambridge?

     (I feel like starting a bikeshed discussion ;-).)

whichever, "bike shed" is two words.

J'
     


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Perl modules

[Andreas Enge]

On Sun, May 11, 2014 at 11:20:33AM +0200, John Darrington wrote:
> On Sun, May 11, 2014 at 10:56:38AM +0200, Andreas Enge wrote:
>      (I feel like starting a bikeshed discussion ;-).)
> whichever, "bike shed" is two words.

Ah, a German mistake!

Andreas

Re: Perl modules

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sat, Dec 07, 2013 at 09:24:42PM +0100, Andreas Enge wrote:
>> All very reasonable. Let us go for this (and I should add a section to the
>> packaging guidelines later on).
>
> Months later, here is a proposed patch in British English. Do we have a rule
> on which spelling to use? British is what I learnt at school.
> (I feel like starting a bikeshed discussion ;-).)

I use American English, as the settings at the end of guix.texi enforce
for those using the Right Editor.  ;-)

I’d prefer to keep it that way, if that’s OK.  WDYT?

>  @node Software Freedom
> @@ -2796,8 +2797,8 @@ Both are usually the same and correspond to the lowercase conversion of the
>  project name chosen upstream.  For instance, the GNUnet project is packaged
>  as @code{gnunet}.  We do not add @code{lib} prefixes for library packages,
>  unless these are already part of the official project name.  But see
> -@ref{Python Modules} for special rules concerning modules for
> -the Python language.
> +@ref{Python Modules} and @ref{Perl Modules} for special rules concerning
> +modules for the Python and Perl languages.

Should be @pxref{Python Modules} and @ref{Perl Modules} (info "(texinfo) @ref").

> +For perl packages containing a single class, we use the lowercase class name,

“Perl”, capitalized.

Also, two spaces after end-of-sentence periods.

Thanks, that’s a useful addition.

Ludo’.

Re: Perl modules

[Andreas Enge]

Thanks for the comments, all implemented and pushed.

On Sun, May 11, 2014 at 11:54:02AM +0200, Ludovic Courtès wrote:
> Also, two spaces after end-of-sentence periods.

Just as a side note (side-note? sidenote?), in texinfo an end of sentence
period immediately followed by a line break is interpreted as such (with a
double space in the info browser), while in the string in the description
field of our package definitions it is not. So there one should not end
a line with a period.

Andreas

Re: Perl modules

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> Thanks for the comments, all implemented and pushed.

Thanks!

> On Sun, May 11, 2014 at 11:54:02AM +0200, Ludovic Courtès wrote:
>> Also, two spaces after end-of-sentence periods.
>
> Just as a side note (side-note? sidenote?), in texinfo an end of sentence
> period immediately followed by a line break is interpreted as such (with a
> double space in the info browser), while in the string in the description
> field of our package definitions it is not. So there one should not end
> a line with a period.

But there’s no tool that really “interprets” of what’s in the
‘description’ field[*].  What do you mean?

Ludo’.

[*] Actually, ‘fill-paragraph’ from (guix ui), which is used for the
    output of ‘guix package --search’ does some very basic
    interpretation.

Re: Perl modules

[Andreas Enge]

On Sun, May 11, 2014 at 01:31:12PM +0200, Ludovic Courtès wrote:
> But there’s no tool that really “interprets” of what’s in the
> ‘description’ field[*].  What do you mean?
> [*] Actually, ‘fill-paragraph’ from (guix ui), which is used for the
>     output of ‘guix package --search’ does some very basic
>     interpretation.

Well, the output of "guix package --search" has different line breaks than
those present in the string of the description field. So something modifies
it, maybe the scheme interpreter itself in what it does with multi-line
strings, maybe the function you mention. In any case, "x.\nY" may be output
as "x. Y"; so if we wish to have double spaces in the output, we need to
write "x.  Y" on the same line.

Andreas

Re: Perl modules

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sun, May 11, 2014 at 01:31:12PM +0200, Ludovic Courtès wrote:
>> But there’s no tool that really “interprets” of what’s in the
>> ‘description’ field[*].  What do you mean?
>> [*] Actually, ‘fill-paragraph’ from (guix ui), which is used for the
>>     output of ‘guix package --search’ does some very basic
>>     interpretation.
>
> Well, the output of "guix package --search" has different line breaks than
> those present in the string of the description field. So something modifies
> it,

Yes, that’s ‘fill-paragraph’.

> maybe the scheme interpreter itself in what it does with multi-line
> strings, maybe the function you mention. In any case, "x.\nY" may be
> output as "x. Y"; so if we wish to have double spaces in the output,
> we need to write "x.  Y" on the same line.

That’s really a bug in ‘fill-paragraph’.

I’m filing it now and will look at it later, unless someone beats me.
;-)

Ludo’.

Re: bug#17468: Perl modules

[Ludovic Courtès]

Fixed in 3a09e1d, which will be in 0.8.

Ludo’.