How about packaging Perl6 modules ?

[Ingy dot Net]

Just a note...

I would avoid conflating Perl 6 modules to Rakudo or Parrot. Perl 6 is only
a language specification (kinda like C++ 98), not a language implementation.
It has many implementations (none of which are called Perl 6), and Rakudo is
just one. If you are going to package modules for the Perl 6 specification,
you should do so without regard to any particular implementation.

Cheers, Ingy

On Wed, Oct 12, 2011 at 1:33 PM, Alessandro Ghedini <al3xbio at gmail.com>wrote:

> Sorry for the delay. Your email somehow got buried in my inbox :/
>
> On Tue, Oct 04, 2011 at 10:47:45AM +0200, Dominique Dumont wrote:
> > On Saturday 01 October 2011 13:58:35 Alessandro Ghedini wrote:
> > > 1) We need a standard way to build those packages (there's no such
> thing
> > >    as ExtUtils::MakeMaker for Perl6). The panda module manager uses a
> > >    script called ufo [0] which basically generates a Makefile out of
> every
> > >    file it finds under lib/, bin/, etc. There are a couple of issues
> with
> > > it though:
> > >
> > >    a) by default it compiles *.pm files to PIR to improve performance.
> This
> > >       may make those files dependant on a specific parrot version.
> > >    b) IIRC it installs those *.pir files to a versioned directory,
> > > something like "/usr/local/lib/parrot/X.Y.Z/..." or so.
> > >       may not work anymore.
> > >
> > >    Both of them may cause all the Perl6 packages to need a rebuild
> after
> > >    each new parrot upload.
> >
> > Which happens every 3 months. Given that there are very few Perl6 modules
> > worth packaging, this may be a valid solution for the short or middle
> term.
>
> It may work in the short term, but doesn't scale very much. I'd rather pick
> up a working (well, at least in theory) model from the beginning, in order
> to avoid us some painful work of "re-do all the packages" (even if they are
> few) in the future.
>
> > >    The obvious solution is to make our own script that does not compile
> > >    to PIR and installs the modules to a directory we want (something
> called
> > >    e.g. dh_perl6). I didn't try yet to write anything useful though.
> Also
> > >    note that this may decrease the performance of modules loading
> > >    significantly (I only tried with the old rakudo in Debian, rakudo
> > >    2011.09 should improve overall performance).
> >
> > Another solution is to have package triggers that re-compile to PIR when
> > parrot is installed
>
> Same as above.
>
> > > 2) According to "Perl 6 Policy" [1], the Perl6 modules should be
> installed
> > >    under "/usr/share/perl6" but rakudo does not "support" it. We should
> > >    patch rakudo to support that path (as the Ruby maintainers are doing
> for
> > >    ruby).
> >
> > May be we could ask upstream.
>
> It looks like a trivial patch, but yes, for the longterm this is preferred.
>
> > > 3) Most of the Perl6 modules [2] do not state copyright and licensing
> > >    information, some of them do not even try to properly version the
> code,
> > >    and other are flagged as "experimental". We should then file bugs
> > >    upstream for every module we would want to package. This is IMHO the
> > >    most serious issue.
> >
> > We can start this way. Once we (as Debian) make some noise about this
> issue,
> > I'm pretty sure that upstream authors will clean up this legal points. At
> > least for modules worth packaging.
>
> Agreed.
>
> > > 4) IIRC some of the modules may not work with the new rakudo 2011.09
> due to
> > >    all the changes it introduces. The risk is that we package some
> modules
> > >    for v2011.07 and then have to remove them, because they don't work
> with
> > >    v2011.09.
> >
> > This may happen. We can mitigate the risk by picking well maintained
> modules
> > (may be LWP::Simple). We can aslo talk with upstream before spending time
> on a
> > "toy" module.
> >
> > At this point, we don't want to package all Perl6 modules. I think that
> just
> > choosing carefully and packaging one or 2 modules will be enough to dig
> up
> > most issues.
>
> Again, agreed.
>
> > > Also, there's no such thing as CPAN for Perl6 so that we would have to
> > > generate the tarballs directly from the git repositories (this wouldn't
> > > have been an issue if modules' maintainers properly versioned their
> modules
> > > with e.g. git tags, given that all of them are on GitHub).
> >
> > Hmm, most of Perl5 strength come from CPAN. Perl6 without a CP6AN (or
> CPAN6,
> > whatever) may never take off. I wonder if (how) current CPAN could host
> Perl6
> > modules ?
>
> Currently the only thing that looks like a centralised repository is this
> https://github.com/perl6/ecosystem
>
> I suspect that the current CPAN infrastructure doesn't work with Perl6
> modules for the same reason that dh-make-perl doesn't: the META.info thing.
> I don't know of any plan for making it work.
>
> Cheers
>
> --
> perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
>
>
> --
> To UNSUBSCRIBE, email to debian-perl-REQUEST at lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster at lists.debian.org
> Archive:
> http://lists.debian.org/20111012173316.GA25606@PC-Ale.fastwebnet.it
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rakudo-devel/attachments/20111012/8eb22e5a/attachment.html>