develooper Front page | perl.module-authors | Postings from December 2011

Re: The CPAN Morass

Linda W
December 5, 2011 18:20
Re: The CPAN Morass
Message ID:
Started this, this morning before any of 'today's emails...just never 
finished it..

Seems pertinent with the talk of alternate packages that only work with 
compilers -- especially those that are limited in the platforms they 
support (Gnu is on
Linux, Windows, Mac, Solaris, Irix, et all...)...

Dana Hudes wrote:
> Solaris Perl is compiled using the Sun C compiler since at least Solaris 8. Once known as Forte now Solaris Studio.
> IDK what Perl on Moc OS X is compiled with but suspect not gcc. A LOT of people write Perl on Mac. 

    Could you defined 'LOT' in terms of % of perl market?    If modules 
written ON the MAC will be generally useful to MOST PERL programmers, 
then -> main index.   Else if only useful to Mac perl users, -> Mac:: world.

BTW -- equally comfortable with them taking a name like "Dirlister::Mac" 
-- if they want to provide a top level "Dirlister" for their functions, 
that's acceptable, only if they acknowledge that 'Dirlister doesn't 
belong to the Mac, and the top level interface is subject to _change_ 
based on design _needs_ ( if it wasn't created to be sufficiently 
general in the same calls for other platforms) AND be open to having new 
functions ADDED for support of new functions/features in the module that 
might be pertinent on other platforms.  Examples:

Good examples:   File::Path,   Path::Class   --   both are platform 
agnostic.. File:Path, *explicitly*,
has platform specific submodules for various OS types: Unix Mac, OS2, 
Win32, VMS. 

Bad example:   Path::Abstract  -- is unix specific.  should be 
Path::Abstract::Unix, in fact says:

    "Path::Abstract is a tool for parsing, interrogating, and modifying
    a UNIX-style path. The parsing behavior is similar to
    <>, except
    that trailing slashes are preserved (converted into a single slash)."

So the author took a Unix function, duplicated it and called it by a 
general name, thoughtful is that?  If the top level 
interface supports the ability to make it generic, then if someone
wants to add another platform: Path::Abstract becomes shared.  and that 
author gets Path::Abstract::Unix.
Later on, if their Path::Abstract::Unix isn't general for Unix, but only 
runs on say, a System-V derivative,
(Solaris, Irix, linux) and someone comes along with a version that 
supports BSD derivatives (SunOS, MacOS), similarly, they  need to be 
willing to move their original code into 
Path::Abstract::Unix::SysV[/BSD]. and have
a top level Unix that calls their code or 'the other code'...

If things are done 'right' at the design phase, the above should be a 
no-brainer --

($ostype =~ /Aix|Bix|Cix/) and goto &__PACKAGE__::SysV; ..... etc...

AT this point, it should be obvious to anyone, that things like the 
above can't be monitored from the top down -- in fact, if no one wants 
to use Pth:Abs" on another platform, nothing would need to change,
Only if 'room needs to be made'...

Note, this SAME problem used to be a problem with just supporting 
multiple VERSIONS of the same modules!  (ex.<>


> Not everyone runs Linux. It is completely legitimate to have CPAN modules which were not even tested on Linux. 
100% agree!

> You may not find their code of interest but to decide it is of no value if it doesn't run on Linux is not terribly clueful.
Yup... I'm  bi-platform @ home, Windows frontend, and linux backend...
I've used SunOS/Solaris/Irix, and worked at Sun/Sgi)... ...

>  I point to the IMHO nice useful Solaris namespace modules on CPAN. 
    Ding Ding Ding... give the solaris folks a prize...(not being 
sarcastic!)... see below)...

Having modules that are platform specific, should be either

   1.  ***minimally***, clearly labeled in descriptions, AND, CPAN
      should allow me to exclude modules that won't run on on the
      platform's i select.  Having a module that only runs on DEC's
      Tops-10, doesn't do many people very much good.  I question it's
      usefulness in being listed in a general directory of modules.
   2. Unless it runs on at least 1 or more dominant platform where perl
      runs, it shouldn't be listed without an OS/ARCH suffix.  If it is
      a generic unix OS type function, it should at least run on linux
      or some free BSD version.   If something was 'Cygwin' only, should
      be labeled such.   Or if such is Win32 only should be labeled such
      (aren't most?) 

   It seems like most of the Win modules have gone the right direction.  
How surprising, that Windows
developers might be clear about what platform their module is designed 
for.  Are developers for other platforms less capable than Windows 

If a module won't run on a standard posix compliant system, using 
standard posix compliant tools, is there a reason why it shouln't have a 
'Mac::' or 'Android::, or 'iPhone' specific prefix  (as random examples)?

    So YEAY, if solaris has already done that... they aren't 
contributing to the main problem space.

(if their modules are broken, only affects other Solarians... ;-)....

>  I don't run Linux: windows at home, Solaris 8, 9, 10 and 11 at work. My personal web space is some Linux variant with a broken gcc and bespoke broken Perl -- they tend to heavily favor PHP.
    Win7 & suse linux... linux does server type stuff... win7 plays 
client..... always a chore making them play nice...

Note -- on the specialty compilers -- if they are designed for a 
platform and it is already under its own namespace, then .. I don't see 
that as being a big problem.

But let me re-iterate the statement which at least _some_ of N.Clark's 
items DON'T qualify on (haven't checked
them all out)...

    1. What compiler on linux -- that supports nearly the same 
environment as that which gave birth
to Perl (sed/awk,shell, grep/sort/...etc)".., that is as freely 
available as Perl and the modules on CPAN
(freely available regarding restrictions of use as well)... would you 
suggest I used?

    2.     In general, as was pointed, out, since Windows is also widely 
used with Perl, the same compiler
should also be available there as well.    I didn't ask for an 
exhaustive list, one compiler that produces as good as [code] and 
supports 32/64 bit linux and windows (all settle for 64 bit only)... but 
having runnable under cygwin would be useful as it is a posix environment...

Oh how ratholed/derailed this day's verbiage has been.

 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About