Front page | perl.perl5.porters |
Postings from December 2019
Re: updating POSIX module for newer functions
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
December 29, 2019 15:32
Subject:
Re: updating POSIX module for newer functions
Message ID:
b342a77c-3cd9-765d-5199-856f7a6c68f8@gmail.com
On 12/28/19 10:51 PM, Eric Wong wrote:
> Sawyer X <xsawyerx@gmail.com> wrote:
>> On 12/17/19 9:18 AM, Eric Wong wrote:
>>>> On Mon, Dec 16, 2019 at 2:51 PM Eric Wong <p5p@yhbt.net> 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 <mark@overmeer.net> wrote:
>>>> There are about 1800 functions in the 2008 release. POSIX.pm
>>>> 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 <grinnz@gmail.com> 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
> CPAN.
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 app.pl that Seacan created.
I can share with you privately the work, if it helps.
[1] https://github.com/gugod/Seacan
[2] https://metacpan.org/pod/distribution/App-FatPacker/bin/fatpack
Thread Previous
|
Thread Next