[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How about packaging Perl6 modules ?



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'


Reply to: