develooper Front page | perl.perl5.porters | Postings from December 2019

Re: updating POSIX module for newer functions

Thread Previous | Thread Next
Sawyer X
December 29, 2019 15:32
Re: updating POSIX module for newer functions
Message ID:

On 12/28/19 10:51 PM, Eric Wong wrote:
> Sawyer X <> wrote:
>> On 12/17/19 9:18 AM, Eric Wong wrote:
>>>> On Mon, Dec 16, 2019 at 2:51 PM Eric Wong <> wrote:
>>>>> Hello all, I noticed POSIX.pod states it's for IEEE Std 1003.1,
>>>>> but I figure it'll be useful to support new functionality...
>>> Hi Mark, Dan; thanks for the responses so far.
>>> Some background here: most users of my software get Perl from
>>> their GNU/Linux distros or BSD ports.  And a big reason why I
>>> choose Perl is that it's widely available out-of-the-box and
>>> users typically don't need to install extra dependencies.
>>> CPAN modules which aren't packaged by the distro are extra
>>> overhead for them to learn, download and install; and they
>>> already complain about dependencies.  Most of them are not Perl
>>> hackers.  Even getting them to consider using software written
>>> in Perl these days is a challenge :<
>>> Mark Overmeer <> wrote:
>>>> There are about 1800 functions in the 2008 release.
>>>> and CORE together support about 100 (but also not really strict) 
>>>> There are some modules on CPAN which implement some additional
>>>> functions.  A few dozen.
>>> Right, some are abandoned and most of those are not available
>>> from distros.
>>>> I started POSIX::1003 which tries to provide all functions... as
>>>> pure as feasible.  But... I need to rework it into a more flexible
>>>> installation structure using Config::AutoConf.  Help welcome ;-)
>>>> When I get help, I will increase its priority.
>>> Any reason you choose to work on a new module rather than
>>> improving the existing POSIX one?  I certainly don't see the
>>> need for all functions in POSIX, especially the ones which
>>> are made redundant by CORE functions.
>>> Dan Book <> wrote:
>>>> If it's at all helpful, it's trivial to write a FFI::Platypus wrapper of
>>>> POSIX functions available on the system, such as I did in Unix::Groups::FFI.
>>> Yup.  I favor Inline(::C) since it's more widely-packaged
>>> (for example, perl-Inline is in CentOS/RHEL 7.x and AFAIK
>>> Platypus is not).
>>> I may even favor syscall() for popular platforms since there's
>>> no extra .so loading and no need to have a compiler installed.
>>> But I consider those dependencies interim solutions because of
>>> the extra installation burden it places on users (and distro
>>> maintainers).  And this probably a big reason why AOT-compiled
>>> languages like Go with giant binaries are gaining favor
>>> nowadays.
>> Is it not possible to go the path that Mark suggests by compiling a big
>> Perl binary with the additional modules?
> I'm trying to reduce the long-term maintenance and update
> overhead, so I wouldn't even consider asking users to
> build/maintain their own Perl install if they aren't comfortable
> with dependencies which require going outside the distro to

This might be out of your scope, but I'll offer this as another option:

I had a project that was self-hosting Perl setup with dependencies
without packaging. The way it worked was:

* A small script that used Seacan[1] to setup a self-contained my
project code, a perl binary, and all dependencies using local::lib.

* The script was then FatPacked[2] so it itself won't require anything
other than perl > v5.10 to generate the full instance (step 1)

When we wanted to build a new version of it, the FatPacked script was
run, created the whole environment using Seacan, and then users could
just run it with that Seacan created.

I can share with you privately the work, if it helps.



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