How about packaging Perl6 modules ?
Alessandro Ghedini
al3xbio at gmail.com
Wed Oct 12 17:33:16 UTC 2011
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'
More information about the Pkg-rakudo-devel
mailing list