Smylers wrote:
John Siracusa writes:John is correct in this case, though. Even if someone can come in after and provide a better solution, unless it is actually part of the base implementation of Perl 6, it will not accomplish the ultimate goals of having a bundling system.
To bring it home, I think packaging and distribution is important
enough to warrant a standard, core-supported implementation. Yes,
it's great to be able to roll your own solution, but forcing the issue
by providing nothing but the most basic features required to bootstrap
a custom solution leads to too much variety and confusion. For some
features, familiarity and standardization are more important.
That only works if the 'core' feature is unquestionably 'right' and
can't be improved upon by somebody else (or indeed by the same person,
but later).
The bundling system needs to simply _be there_. A developer needs to know that anywhere they find Perl 6 on a system that has some concept of 'files' their bundle will run (unless of course the bundle contains platform dependent libraries â now, *that* is a problem for a external module (or is it?)).
Even if the ultimate choice of a built-in bundling system is utterly wrong, it is hardly less wrong that having none at all. Besides, if we implement a bundling system that cannot be trivially expanded into something more glorious than we have definitely gotten it wrong. (So let's not do that.)
I think a minimalist approach is best. James Mastros suggested something that seems to be be unquestionably 'right'.
James Mastros wrote:
We can, and I think should, write a one-paragraph documentation, one-screenful implementation of this that's in perl core:
As a special case, if the "filename" argument to perl is a directory,
and the directory contains a file named "main.pl", then the directory
is prepended to @*INC, and main.pl is run.
He expounds beyond that on how to include support for archives.
This solution seems to give us the best of both worlds. The user can easily expand this mechanism to use something like PAR (if not 'PAR for Perl 6' itself), or any module they like. And the basic bundling system gives them the ability to bundle their bundling system into the bundle! ( â so I can bundle in my platform dependent library extension â)
For most applications, James solution is more than adequate. For anything more complicated than that, including it in the "official" implementation might be a mistake. Then again, it might not.
The more I think about it, the greater the benefit there seems to be in having a standardized way to include multi-platform C libraries in a perl bundle. The Mac OS X bundles work this way (though no one really uses this feature). But that can of worms is so large that â despite its utility â I cannot (quite) justify the cost.
Application distribution is a pain. Let's make Perl application distribution easier.
Gregory Keeney
