Re: Perl modules

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’.