Proposal: templating system
Xavier Noria
be a good idea to include _some_ templating system in the standard
distribution.
I use templates quite often and sometimes, e.g. automation of
installation/configuration of server-side software in several machines,
I would appreciate to be able to rely on the existence of the same
templating system everywhere. Not necessarily as a point in favour of
this proposal, but maybe it's worth noting that recent rubys come with
ERB.
If I had to vote for a templating system to be distributed with perl I
would certainly suggest Text::Template, which in my opinion has the
right balance as a general-purpose solution, providing a powerful but
simple interface, a couple of .pm files, and good documentation.
-- fxn
Rafael Garcia-Suarez
> Well, I don't know how to justify this objectively but I think it would
> be a good idea to include _some_ templating system in the standard
> distribution.
I don't think so. Why ?
- There are so many templating systems, with different characteristics.
- templating systems tend to evolve faster than the perl distribution,
or to become obsolete (if we put one in the core, we'll need to
support it forever, like CGI.pm for example) or to have too many
dependencies
- templating systems are not general-purpose modules. A sysadmin
will probably not use it. A TT user will loathe the space wasted
by Mason on his hard drive :)
- the perl distribution is already too big. We can't trim it
for backward-compatibility reasons but the core distribution
of Perl 6 will probably include only the modules that are
absolutely necessary to fetch and install the others.
- CPAN(PLUS)? makes it easy to package stuff and deploy it
(see bundles).
Xavier Noria
> Quoting Xavier Noria <f...@hashref.com>:
>
>> Well, I don't know how to justify this objectively but I think it
>> would
>> be a good idea to include _some_ templating system in the standard
>> distribution.
>
> I don't think so. Why ?
> - There are so many templating systems, with different characteristics.
Well, I don't see this as a drawback. Among the ones available some
would have to be choosen according to the constraints of a
distribution.
> - templating systems tend to evolve faster than the perl distribution,
> or to become obsolete (if we put one in the core, we'll need to
> support it forever, like CGI.pm for example) or to have too many
> dependencies
Not necessarily, and in the case of Text::Template this is certainly
not the case.
> - templating systems are not general-purpose modules. A sysadmin
> will probably not use it. A TT user will loathe the space wasted
> by Mason on his hard drive :)
Of course, big systems such as Mason or TT would not be among the ones
I would consider for this.
> - the perl distribution is already too big.
This could be argued for most standard modules.
> We can't trim it
> for backward-compatibility reasons but the core distribution
> of Perl 6 will probably include only the modules that are
> absolutely necessary to fetch and install the others.
> - CPAN(PLUS)? makes it easy to package stuff and deploy it
> (see bundles).
This could be said of most standard modules as well.
There are suitable modules in my opinion to provide this functionality
in the core distribution, so in the end it's a matter of opinion. I
think it would be good, but of course I understand someone else's view
can differ.
-- fxn
Michael G Schwern
> >I don't think so. Why ?
> >- There are so many templating systems, with different characteristics.
>
> Well, I don't see this as a drawback. Among the ones available some
> would have to be choosen according to the constraints of a
> distribution.
The drawback is that no matter what templating system we decided to
incorporate, there would always remain a large wad of people who are
dissatisified with our choice. And chosing a template system based on its
lack of dependencies is not a good way to pick a templating system.
Rather than get involved in that, its best to just let people make their
own choice and make it as easy as possible for them to install modules.
For this reason (and others), the unofficial policy on new modules is that
if it doesn't help to build, test or document Perl or if it doesn't help to
install more modules, its not likely to get in.
> >- the perl distribution is already too big.
>
> This could be argued for most standard modules.
Yes, and it has been. We'd love to throw a lot of them out but we can't for
the reasons Rafel gave below. If we can't trim the Perl dist down, we'd at
least rather not make it larger.
> >We can't trim it
> > for backward-compatibility reasons but the core distribution
> > of Perl 6 will probably include only the modules that are
> > absolutely necessary to fetch and install the others.
> >- CPAN(PLUS)? makes it easy to package stuff and deploy it
> > (see bundles).
>
> This could be said of most standard modules as well.
See above.
--
Michael G Schwern sch...@pobox.com http://www.pobox.com/~schwern/
We're talkin' to you, weaselnuts.
http://www.goats.com/archive/000831.html
Yves Orton
> modules is that
> if it doesn't help to build, test or document Perl or if it
> doesn't help to
> install more modules, its not likely to get in.
Id just like to point out how common it is to hear people say "we cant use
any modules not distributed with Perl" which means a whole load of crap
duplicated code out there.
If the policy is that useful but nonessential stuff doesnt get included (a
wise decision IMO) then perhaps a list of modules known to the core
developers to be reliable but not appropriate for inclusion could be de
added to the distro.
If the core distro said "Hey we would have included Foo::Bar but for this
policy of not including modules needed to build Perl" (or whatever) then I
think a lot of people would be able to win the "no non standard modules"
argument more often, at least for a wider list of modules of known quality.
Just a thought anyway
Yves
Rafael Garcia-Suarez
> > For this reason (and others), the unofficial policy on new
> > modules is that
> > if it doesn't help to build, test or document Perl or if it
> > doesn't help to
> > install more modules, its not likely to get in.
>
> Id just like to point out how common it is to hear people say "we cant use
> any modules not distributed with Perl" which means a whole load of crap
> duplicated code out there.
I think that this argument has more to do with superstition than
with technical reality.
> If the policy is that useful but nonessential stuff doesnt get included (a
> wise decision IMO) then perhaps a list of modules known to the core
> developers to be reliable but not appropriate for inclusion could be de
> added to the distro.
>
> If the core distro said "Hey we would have included Foo::Bar but for this
> policy of not including modules needed to build Perl" (or whatever) then I
> think a lot of people would be able to win the "no non standard modules"
> argument more often, at least for a wider list of modules of known quality.
The perlfaq already includes pointers to CPAN modules for several
common questions ; seems to me that it's a good place for this information
to be.
Yves Orton
> say "we cant use
> > any modules not distributed with Perl" which means a whole
> load of crap
> > duplicated code out there.
>
> I think that this argument has more to do with superstition than
> with technical reality.
Oh, I wasnt implying the argument had any more merit than the rank of the
person espousing it. But being that I see this regularly on perlmonks it
seems there are a lot of stupid people making policy for perl use.
> > If the core distro said "Hey we would have included
> Foo::Bar but for this
> > policy of not including modules needed to build Perl" (or
> whatever) then I
> > think a lot of people would be able to win the "no non
> standard modules"
> > argument more often, at least for a wider list of modules
> of known quality.
>
> The perlfaq already includes pointers to CPAN modules for several
> common questions ; seems to me that it's a good place for
> this information
> to be.
Maybe a list of modules that are "p5p approved" but not distributed for
policy reasons could go there? I could put together a proposal list with
help of the folks at PM and come back to the list with it.
Yves
Michael G Schwern
> If the policy is that useful but nonessential stuff doesnt get included (a
> wise decision IMO) then perhaps a list of modules known to the core
> developers to be reliable but not appropriate for inclusion could be de
> added to the distro.
I don't believe such a list should be maintained in the core for the reasons
that it would rapidly fall out of date as each Perl release ages, that p5p
isn't a terribly good cross-section of Perl developers to maintain such a
list and, finally, I don't think p5p needs more work.
Instead, I reference you to the Phalanx project.
http://qa.perl.org/phalanx/
> If the core distro said "Hey we would have included Foo::Bar but for this
> policy of not including modules needed to build Perl" (or whatever) then I
> think a lot of people would be able to win the "no non standard modules"
> argument more often, at least for a wider list of modules of known quality.
Sounds like a good perlfaq2 entry... if we can get some sort of policy
blessing from the pumpkings.
--
Michael G Schwern sch...@pobox.com http://www.pobox.com/~schwern/
Let's leave my ass out of this, shall we?
Randy W. Sims
>>>If the core distro said "Hey we would have included
>>
>>Foo::Bar but for this
>>
>>>policy of not including modules needed to build Perl" (or
>>
>>whatever) then I
>>
>>>think a lot of people would be able to win the "no non
>>
>>standard modules"
>>
>>>argument more often, at least for a wider list of modules
>>
>>of known quality.
>>
>>The perlfaq already includes pointers to CPAN modules for several
>>common questions ; seems to me that it's a good place for
>>this information
>>to be.
>
>
> Maybe a list of modules that are "p5p approved" but not distributed for
> policy reasons could go there? I could put together a proposal list with
> help of the folks at PM and come back to the list with it.
>
> Yves
>
This sounds like Phalanx / CPANTS / Kwalitee
<http://qa.perl.org/phalanx/>. It also brings to mind CPAN ratings
<http://cpanratings.perl.org/>
Tim Bunce
>
> > >- the perl distribution is already too big.
> >
> > This could be argued for most standard modules.
>
> Yes, and it has been. We'd love to throw a lot of them out but we can't for
> the reasons Rafel gave below. If we can't trim the Perl dist down, we'd at
> least rather not make it larger.
The plan (or at least A plan) was to structure future perl releases as
a CORE + SDK. Where that particular SDK would be just all the modules
in the current distribution that are not required to build perl.
See the SDK section about two thirds of the way down in here:
http://cplan.kwiki.org/index.cgi?MinutesAccordingToAutrijus
Tim.
Yves Orton
> >>common questions ; seems to me that it's a good place for
> >>this information
> >>to be.
> >
> >
> > Maybe a list of modules that are "p5p approved" but not
> distributed for
> > policy reasons could go there? I could put together a
> proposal list with
> > help of the folks at PM and come back to the list with it.
> >
> > Yves
> >
>
> This sounds like Phalanx / CPANTS / Kwalitee
> <http://qa.perl.org/phalanx/>. It also brings to mind CPAN ratings
> <http://cpanratings.perl.org/>
The problem is that these sites and such dont have that "Standard Perl
Distribution" officialness that I think is needed to win the argument
against the PHB. Anybody that would take these sites as viable argument
probably arent the people enforcing these policies.
Yves
Alan Burlison
>>Yes, and it has been. We'd love to throw a lot of them out but we can't for
>>the reasons Rafel gave below. If we can't trim the Perl dist down, we'd at
>>least rather not make it larger.
>
> The plan (or at least A plan) was to structure future perl releases as
> a CORE + SDK. Where that particular SDK would be just all the modules
> in the current distribution that are not required to build perl.
>
> See the SDK section about two thirds of the way down in here:
> http://cplan.kwiki.org/index.cgi?MinutesAccordingToAutrijus
No more in core. Please. One of the painful tasks I have to do every time
I integrate perl into Solaris is to rip the bloatball into two so I can fit
a subset of perl into the miniroot (boot CD), and hope that I don't miss
anything vital. The inexorable growth of perl is getting to be a real pain
for anyone who has minimal footprint requirements. This time round I've had
to rip out all the unicode stuff just so I could wedge it in. It would be
really nice if we had some agreed way of doing this carveup. e.g.
runtime-only (no ability to build addon modules), minimal (enough to get
CPAN to work) & the full-fat (the artery-hardening version).
I like Tim's SDK suggestion, but I'd take it even further than that.
--
Alan Burlison
--
Rafael Garcia-Suarez
> No more in core. Please. One of the painful tasks I have to do every time
> I integrate perl into Solaris is to rip the bloatball into two so I can fit
> a subset of perl into the miniroot (boot CD), and hope that I don't miss
> anything vital. The inexorable growth of perl is getting to be a real pain
> for anyone who has minimal footprint requirements. This time round I've had
> to rip out all the unicode stuff just so I could wedge it in. It would be
> really nice if we had some agreed way of doing this carveup. e.g.
> runtime-only (no ability to build addon modules), minimal (enough to get
> CPAN to work) & the full-fat (the artery-hardening version).
>
> I like Tim's SDK suggestion, but I'd take it even further than that.
A good starting point for whoever wants to investigate doing
a "mini-core-sdk" would be to see what you were able to cut out.
Alan Burlison
> A good starting point for whoever wants to investigate doing
> a "mini-core-sdk" would be to see what you were able to cut out.
I got it down from 25Mb to about 5Mb - I can supply a file list to anyone
who is interested.
--
Alan Burlison
--
Redvers Davies
> I got it down from 25Mb to about 5Mb - I can supply a file list to anyone
> who is interested.
I would be very interested in what you trimmed it down to. I have been
trying to trim it down even more than that and it would be good to
compare our lists.
Michael G Schwern
> A good starting point for whoever wants to investigate doing
> a "mini-core-sdk" would be to see what you were able to cut out.
Debian's knocked their perl-base binary package down to about two megs
installed.
http://packages.debian.org/testing/base/perl-base
They build it from the complete source, so this isn't a good indication of
what's needed to build Perl, but rather what's needed to run it.
--
Michael G Schwern sch...@pobox.com http://www.pobox.com/~schwern/
If at first you don't succeed, call in an air strike.
David
Xavier Noria wrote:
> Well, I don't know how to justify this objectively but I think it would
> be a good idea to include _some_ templating system in the standard
> distribution.
You know what? Perl _does_ include not just one, but three
templating systems in itself
and has since the beginning. One templating system is called
"interpolated quoting." Another templating system Perl includes
is very powerful and is called "eval." And a third is called
"the substitution operator."
Contact me off-list for examples if you need. ( or just read on,
I appear to be prolix at the moment)
*******
By the way, has anyone written a perl module to correctly interpret the
"Smarty" templating language? My PHP-using co-workers claim it is
becoming the de-facto standard in PHP. This strikes me as odd because
I thought PHP was itself a templating system, but it seems the division
of labor between Modern HTML and Process has become such that it is no
longer enough to embed PHP in web pages, and the PHP "web applications"
are now explicitly generating their output from read-in external files
just like the Perl templating systems. Go figure.
I still think "core perl" is all the template engine anyone would ever
need. Create a file with a series of template definitions in it,
load variables into a hash, copy the template and run a substitution
operator on the copy to do your interpolation without fear of arbitrary
code appearing in your templates, output the revised copy.
No, no example is forthcoming here.
Dave Mitchell
> You know what? Perl _does_ include not just one, but three
> templating systems in itself
> and has since the beginning. One templating system is called
> "interpolated quoting." Another templating system Perl includes
> is very powerful and is called "eval." And a third is called
> "the substitution operator."
There is a big difference between those and a full-blown templating
system (eg HTML::Mason). Each has their own domain of usefulness,
and suggesting that people can get by with just Perl's built-in
facilities is not helpful. This is of course a completely separate
issue to whether some such system should go in the core, to which
I personally happen to be opposed.
Dave.
--
To collect all the latest movies, simply place an unprotected ftp server
on the Internet, and wait for the disk to fill....
Alan Burlison
> Debian's knocked their perl-base binary package down to about two megs
> installed.
> http://packages.debian.org/testing/base/perl-base
>
> They build it from the complete source, so this isn't a good indication of
> what's needed to build Perl, but rather what's needed to run it.
That looks like a reasonable set of modules - I just included a few more to
use up my space budget ;-)
Interestingly they've taken out the unicode stuff as well. There are any
number of ways of doing this, it would be nice if there were a set number of
standard ways.
--
Alan Burlison
--
Dave Rolsky
> I still think "core perl" is all the template engine anyone would ever
> need. Create a file with a series of template definitions in it,
> load variables into a hash, copy the template and run a substitution
> operator on the copy to do your interpolation without fear of arbitrary
> code appearing in your templates, output the revised copy.
Good point. I think I'll remove Mason from CPAN ASAP. Obviously it's
just wasting space ;)
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
Xavier Noria
> On Thu, Feb 05, 2004 at 04:24:04PM -0600, david wrote:
>> You know what? Perl _does_ include not just one, but three
>> templating systems in itself
>> and has since the beginning. One templating system is called
>> "interpolated quoting." Another templating system Perl includes
>> is very powerful and is called "eval." And a third is called
>> "the substitution operator."
>
> There is a big difference between those and a full-blown templating
> system (eg HTML::Mason). Each has their own domain of usefulness,
> and suggesting that people can get by with just Perl's built-in
> facilities is not helpful. This is of course a completely separate
> issue to whether some such system should go in the core, to which
> I personally happen to be opposed.
Maybe I wasn't clear enough about this point: The templating systems I
have in mind in this proposal are assumed to be small in size.
-- fxn
Yitzchak Scott-Thoennes
By unicode stuff, do you mean ext/Encode (reasonable, and installable
from CPAN) or lib/unicore in toto (I hope not!)?
Alan Burlison
>>Interestingly they've taken out the unicode stuff as well. There are any
>>number of ways of doing this, it would be nice if there were a set number
>>of standard ways.
>
> By unicode stuff, do you mean ext/Encode (reasonable, and installable
> from CPAN) or lib/unicore in toto (I hope not!)?
lib/unicore. I've done the same - it's just *way* too big. For Solaris
I've put it in another package that automatically gets installed, it's just
not there in the cut-down perl you get on the boot CD. The idea is that
people can use perl to write custom JumpStart srcipts on Solaris, once the
OS is installed you then have the full distro. I assume RH have done the
same sort of thing.
--
Alan Burlison
--
Tim Bunce
Yes: multiple SDKs.
The key point is that perl is currently monolithic as far as most
people are concerned. You "install perl". If we can change that *mindset*
to "install perl plus an SDK" then we've made a significant advance.
Even if 99.371% of the time the "perl+SDK" installed is identical to
the current perl distribution. It's the change in thinking that's important.
It's important because it opens the way for alternate SDKs. It's
quite clear that many people want an SDK with more than the current
core modules, and it's quite clear that some people (debian and Sun,
for example) have uses for SDKs smaller than the current core modules.
I'd like to see us end up with at least:
a) perl + only modules required to build it
with options to install less than that,
perhaps with options to skip building parts
b) perl + current set of modules
c) perl + many modules (see below for which :-)
You could think of these as "P5RE: Perl5 Reduced Edition" (no SDK),
"P5SE: Perl5 Standard Edition" (Core SDK), and "P5EE: Perl5
Enterprise Edition" (Enterprise SDK) if you like. (But lets not
argue about the names now, it's the concept we need to discuss.)
Then, and this is a key part, a "perl release" would actually
release *three* .tar.gz files and people would have to choose one.
[A slight digression: In terms of source code directory structure
I imagine an sdk_core directory into which all the current
non-essential modules are moved and grouped into subdirectories
with their own Makefile.PL and test suites - as if they were
CPAN distributions. Similarly an sdk_enterprise directory
would hold the specific versions of distributions that are
deemed stable and have been tested together.]
It seems likely that ISP's and hosting companies would adopt P5EE
as their standard perl bundled into their service offerings.
As for what modules to include in P5EE it's clear that no two people
are likely to agree. So, rather than have this thread drift off into
a debate about that, let's discuss the principles and not name
specific modules till we're agreed this is going to happen.
Here are the principles I'm thinking of, it's a short list:
1. Mature, widely used, and actively supported by a developer
(let's not try to define those terms, please)
2. Multiple modules the same topic are okay
(don't try to pick the "one best <foo> module", it can't be done)
I've not mentioned portability/quality/kwality etc because it's covered
sufficiently by "Mature, widely used, actively supported by developer".
Naturally any modules included will get a lot of extra attention and
any remaining portability / quality issues will be addressed along the way.
Tim.
Yves Orton
> > Michael G Schwern wrote:
> >
> > >Debian's knocked their perl-base binary package down to
> about two megs
> > >installed.
> > >http://packages.debian.org/testing/base/perl-base
> > >
> > >They build it from the complete source, so this isn't a
> good indication of
> > >what's needed to build Perl, but rather what's needed to run it.
> >
> > That looks like a reasonable set of modules - I just
> included a few more to
> > use up my space budget ;-)
> >
> > Interestingly they've taken out the unicode stuff as well.
> There are any
> > number of ways of doing this, it would be nice if there
> were a set number
> > of standard ways.
>
> Yes: multiple SDKs.
>
> The key point is that perl is currently monolithic as far as most
> people are concerned. You "install perl". If we can change
> that *mindset*
> to "install perl plus an SDK" then we've made a significant advance.
I think this is a great point. Convincing the PHB's that its ok to install
CPAN stuff would be much easier if there were multiple "standard versions"
to use which had less and more modules included. I just hope one of the
sdk's is called "kitchen-sink" and includes just about everything but.
cheers.
Yves
Craig A. Berry
Tim....@pobox.com (Tim Bunce) wrote:
> The key point is that perl is currently monolithic as far as most
> people are concerned. You "install perl".
Maybe the reason people think this way is they've been told to, and --
more importantly -- have been promised that they don't have to think of
it any other way. From Camel 3 p. 831:
"Because the standard modules are available everywhere, if you use one
of them in your program, you can run your program anywhere Perl is
installed, without any extra installation steps."
> I'd like to see us end up with at least:
>
> a) perl + only modules required to build it
> with options to install less than that,
> perhaps with options to skip building parts
> b) perl + current set of modules
> c) perl + many modules (see below for which :-)
>
> You could think of these as "P5RE: Perl5 Reduced Edition" (no SDK),
> "P5SE: Perl5 Standard Edition" (Core SDK), and "P5EE: Perl5
> Enterprise Edition" (Enterprise SDK) if you like. (But lets not
> argue about the names now, it's the concept we need to discuss.)
>
> Then, and this is a key part, a "perl release" would actually
> release *three* .tar.gz files and people would have to choose one.
Except for porters and pumpkings, who would have to choose all three
and thus triple their testing and release management work to get a Perl
release out the door.
I'm all for providing a standard way to produce a pared-to-the-bone
binary kit that vendors can easily slip into an installer, but I don't
see why this would require a separate source distribution.
Providing a standard suite of approved add-ons is probably worth
discussing, but it strikes me as a very different kind of proposal for
a different target audience than the pared-down kit.
David
Craig A. Berry wrote:
>>I'd like to see us end up with at least:
>>
>>a) perl + only modules required to build it
>> with options to install less than that,
>> perhaps with options to skip building parts
>>b) perl + current set of modules
>>c) perl + many modules (see below for which :-)
>>
>>You could think of these as "P5RE: Perl5 Reduced Edition" (no SDK),
>>"P5SE: Perl5 Standard Edition" (Core SDK), and "P5EE: Perl5
>>Enterprise Edition" (Enterprise SDK) if you like. (But lets not
>>argue about the names now, it's the concept we need to discuss.)
I prefer "light" to "reduced edition"
>>Then, and this is a key part, a "perl release" would actually
>>release *three* .tar.gz files and people would have to choose one.
> Except for porters and pumpkings, who would have to choose all three
> and thus triple their testing and release management work to get a Perl
> release out the door.
Not if paring and releasing the light edition is a separate project,
for instance the aforementioned 2M debian binary package
> I'm all for providing a standard way to produce a pared-to-the-bone
> binary kit that vendors can easily slip into an installer, but I don't
> see why this would require a separate source distribution.
me neither. What we could provide would be a standard way to list
what is in a pared-down version, in order to facilitate the paring-down
process for releasers and maintainers of reduced Perls
> Providing a standard suite of approved add-ons is probably worth
> discussing, but it strikes me as a very different kind of proposal for
> a different target audience than the pared-down kit.
We're already doing all of this, or at least we're already doing the
parts of it that CPAN bundles succeed at.
Tim Bunce
> In article <20040206115...@dansat.data-plan.com>,
> Tim....@pobox.com (Tim Bunce) wrote:
>
> > The key point is that perl is currently monolithic as far as most
> > people are concerned. You "install perl".
>
> Maybe the reason people think this way is they've been told to, and --
> more importantly -- have been promised that they don't have to think of
> it any other way. From Camel 3 p. 831:
>
> "Because the standard modules are available everywhere, if you use one
> of them in your program, you can run your program anywhere Perl is
> installed, without any extra installation steps."
"standard modules" are available in the "standard edition".
They're also available in the "enterprise edition".
(Very few people would be interested in the "reduced edition"
and those who are are already releasing cut-down perl's
but with _differing_ subsets of modules.)
> > I'd like to see us end up with at least:
> >
> > a) perl + only modules required to build it
> > with options to install less than that,
> > perhaps with options to skip building parts
> > b) perl + current set of modules
> > c) perl + many modules (see below for which :-)
> >
> > You could think of these as "P5RE: Perl5 Reduced Edition" (no SDK),
> > "P5SE: Perl5 Standard Edition" (Core SDK), and "P5EE: Perl5
> > Enterprise Edition" (Enterprise SDK) if you like. (But lets not
> > argue about the names now, it's the concept we need to discuss.)
> >
> > Then, and this is a key part, a "perl release" would actually
> > release *three* .tar.gz files and people would have to choose one.
>
> Except for porters and pumpkings, who would have to choose all three
> and thus triple their testing and release management work to get a Perl
> release out the door.
The "standard edition" would continue to be where the work is done.
All that's needed is to reorg the codebase so non-"reduced" modules
live in a separate directory along with their tests.
The only extra work the "reduced edition" needs is a configure and
build with that separate directory chmod'd to be non-readable
(if you want to be paranoid). That's it.
For the "enterprise edition" I'd expect someone to be nominated
to maintain a Bundle file listing the exact versions of the
extra modules to be included (and SDK Pumpkin effectively).
All the Perl Pumpkin has to do is update the local copy of those
distributions when the SDK Pumpkin changes the bundle (which should
not be often).
Some tinderboxes could be changed to test the enterprise edition.
> I'm all for providing a standard way to produce a pared-to-the-bone
> binary kit that vendors can easily slip into an installer, but I don't
> see why this would require a separate source distribution.
It doesn't really need separate source distribution. The only
difference would be the presence or absence of a single subdirectory.
However, a separate source distribution does provide for a smaller
download (for the few who would want it) but more importantly
strenthens the wider message that "perl is very small, you should
install it with an SDK of your choice".
> Providing a standard suite of approved add-ons is probably worth
> discussing, but it strikes me as a very different kind of proposal for
> a different target audience than the pared-down kit.
It is certainly for a different target audience. But there's an
important underlying shift in perspective that is relevant to both.
Tim.
Alan Burlison
> (Very few people would be interested in the "reduced edition"
> and those who are are already releasing cut-down perl's
> but with _differing_ subsets of modules.)
I'd prefer to release a standard set rather than having to make it up as I
go along.
--
Alan Burlison
--
Scott Walters
>
> ...
>
> "standard modules" are available in the "standard edition".
> They're also available in the "enterprise edition".
There is a lot of merit to this. People tend to write code to use
the least number of CPAN modules possible to easy moving the code
in the future. This is a shame, with all of the wonderful stuff on
CPAN. It is also a one-up by Java, who provides a large library
including things for specialized purposes and including an
"enterprise" addition with crypto and RMI and such. The difference
is a small amount of work and perception, but this builds a
default, and defaults are extremely powerful in influencing
people.
My wish list:
* Create something like Acme::SoftwareUpdate that will go off and install
modules automatically if they're use'd but not installed. Perl 6 "has" it,
it's a good idea, it's do-able, so should Perl 5. Bundle it.
* Include and advertisie PAR as a de facto standard even though it's young
* Include most of Net::, include XML, Compress::, and other things that
should be in an API (language aside), all in the standard distribution
Yes, this attacks from every angle (that I can think of).
Also,
* I don't use a template system, but if any of them work as a source
filter and let you intermingle Perl and HTML rather than implementing
a mini-language on top of Perl, throw it in. That's would break the
Mason/AxKit/Template::Toolkit/etc tie by virtue of being a PHP/ASP style
template system rather than one designed to seperate code and HTML
(like people should be using, but who are we to tell them what to do?).
The whole suite of proper template systems could be included in an
enterprise addition.
>
> (Very few people would be interested in the "reduced edition"
> and those who are are already releasing cut-down perl's
> but with _differing_ subsets of modules.)
Except p5p who has to support it =)
perlbug could be modified to direct traffic relating to modules
to another list, such as the already existing cpan modules list. A
larger support community isn't impossible. A larger talent pool is
availble to potentially field questions - few people are qualified to
post on p5p (and certainly not me).
Modest suggestions.
Thanks, best reguards,
-scott
Michael G Schwern
> > This sounds like Phalanx / CPANTS / Kwalitee
> > <http://qa.perl.org/phalanx/>. It also brings to mind CPAN ratings
> > <http://cpanratings.perl.org/>
>
> The problem is that these sites and such dont have that "Standard Perl
> Distribution" officialness that I think is needed to win the argument
> against the PHB. Anybody that would take these sites as viable argument
> probably arent the people enforcing these policies.
Its a perl.org site, of course its official! ;)
--
Michael G Schwern sch...@pobox.com http://www.pobox.com/~schwern/
We have returned to claim the pyramids.
Richard Clamp
> * Create something like Acme::SoftwareUpdate that will go off and
> install
> modules automatically if they're use'd but not installed. Perl 6 "has"
> it,
> it's a good idea, it's do-able, so should Perl 5. Bundle it.
>
And by Perl 6 you mean...?
Yes it's doable, I can tell as it's already been done as
Acme::Intraweb. However, as someone who has to maintain services
written in perl, I'm going to disagree with you very strongly about it
being a good idea.
--
Richard Clamp <rich...@unixbeard.net>
Randy W. Sims
>
> Craig A. Berry wrote:
>
>>> I'd like to see us end up with at least:
>>>
>>> a) perl + only modules required to build it
>>> with options to install less than that,
>>> perhaps with options to skip building parts
>>> b) perl + current set of modules
>>> c) perl + many modules (see below for which :-)
>>>
>>> You could think of these as "P5RE: Perl5 Reduced Edition" (no SDK),
>>> "P5SE: Perl5 Standard Edition" (Core SDK), and "P5EE: Perl5
>>> Enterprise Edition" (Enterprise SDK) if you like. (But lets not
>>> argue about the names now, it's the concept we need to discuss.)
>
>
> I prefer "light" to "reduced edition"
Base Perl = gem; Extended Perl = Mother-of-Perl ;-)
Another way to organize the Modules would be to group them into tasks;
Data-Munging, Web-Generation, Administration, etc. Installing base perl
+ all tasks == standard perl.
FWIW, I like the idea of breaking perl up; at least as far as producing
a minimal perl and one or more bundles that == standard perl. I think it
helps with people's perception of perl in that new users are sometimes
overwhelmed by the number of modules much like new users when they
install a linux distribution for the first time who have never worked
with it before - There are so many packages that you don't know what you
need, where to start, etc. Also with the increasing number of small
devices, network appliances, etc., having a minimal perl would make it
feasible to place perl on platforms with limited space.
One thing that I am concerned with is declaring certain modules as
standard (outside of those that are already standard). Would it be a
barrier against innovation? or an enabler? When there are two or more
modules that perform a similar task and one is chosen as standard, what
will happen to the others? Survival of the fittest? What if someone
comes up with a new innovative and better way of doing something that a
standard module does? If you pick a best-of in every case where there is
more than one module doing the same thing, what will happen?
I'm not arguing one way or the other. I'm not ever sure it is an issue,
but it seems worth considering.
Regards,
Randy
PS: FWIW, I'm very opposed to java-esque names - P5EE - yuck! Perl has
it's own culture and it's own way of doing things - Let's please not
imitate java.
Paul Johnson
> It's important because it opens the way for alternate SDKs. It's
> quite clear that many people want an SDK with more than the current
> core modules, and it's quite clear that some people (debian and Sun,
> for example) have uses for SDKs smaller than the current core modules.
>
>
> I'd like to see us end up with at least:
>
> a) perl + only modules required to build it
> with options to install less than that,
> perhaps with options to skip building parts
> b) perl + current set of modules
> c) perl + many modules (see below for which :-)
As I recall, something similar to this is a part of Hugo's stated goals
for 5.10.
--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net
Brendan O'Dea
It's probably worth noting that the process of building perl-base is an
inclusive, rather than exclusive one--which is to say that I didn't take
out unicode, rather I left it out. The package is created by splitting
off a chunk of the full install.
The purpose of perl-base is to provide a bare-bones interpreter both for
the installer, and for package maint ({pre,post}inst) and config scripts
which may be called prior to the full perl package being installed.
As such, I created the initial module list by a semi-automated process
which determined what modules were in use by such mechanisms and
internally by perl at the time (early 5.6.0, so most uses were still
consistent with 5.005). Subsequently the list has been augmented with
additional modules as required/requested[0].
The end result of this evolutionary mess[1] is that perl-base is
probably more representative of the minimal set of modules in use by
Debian for basic tasks rather than an exhaustive analysis of what would
comprise an optimally small perl installation.
[0] For those interested, you can see the current list by applying
http://ftp.debian.org/debian/pool/main/p/perl/perl_5.8.3-1.diff.gz
to 5.8.3 and then looking at debian/perl-base.files{,.shared}.
[1] B::Deparse for example is included, for reasons I can now neither
recall nor fathom.
--bod
Horsley Tom
>installed.
There is one old discussion that hasn't been merged into this
thread yet, so I figure it is time :-).
What ever happened to teaching perl to load modules from .zip files
(or something like them)? A lot of the modules (the pure perl ones
especially) would compress exceedingly well, and you could get a
smaller perl footprint and still have many of the base modules included.
(And to go completely off-topic, a compressed perl library would
solve the "problem" of unicode module names since you wouldn't
need to depend on the native file system for storing names).
Dave Mitchell
data point: 5.8.3 on Solaris:
6Mb bin/
11Mb man/
12Mb lib/*.so
6Mb lib/*.a
4Mb lib/*.pod
4Mb lib/*.pm
3Mb lib/*.txt
1Mb lib/*.pl
1Mb lib/*.h
--
Fire extinguisher (n) a device for holding open fire doors.
Tim Bunce
Yes. Hugo was also at the same CPLAN meeting.
It was also one of Larry's goals for perl6. See
http://dev.perl.org/perl6/talks/2001/onion5.pdf
Talk 30: "The Standard Perl Library":
° Definitions of Standard become mushy
° Cut core down to almost nothing, and force installation of a more complete SDK
° Multiple such SDKs are possible, just as with Linux distributions
° SDK editors earn trust by recommending reliable sets of modules
(That was in 2001, but I doubt there's been a significant change.)
Tim.
Nicholas Clark
> >installed.
>
> There is one old discussion that hasn't been merged into this
> thread yet, so I figure it is time :-).
>
> What ever happened to teaching perl to load modules from .zip files
> (or something like them)? A lot of the modules (the pure perl ones
C the PANacea.
http://search.cpan.org/~nwclark/ex-lib-zip/
[Although I don't seem to be able to find Acme::SolveHaltingProblem there :-( ]
Nicholas Clark
Abigail
> Rafael Garcia-Suarez wrote:
>
> >A good starting point for whoever wants to investigate doing
> >a "mini-core-sdk" would be to see what you were able to cut out.
>
> who is interested.
5 Mb! Luxury. I could use a tiny Perl. But I only have about 700 kb
left on the floppy for the Linux distro I'm working on.
Abigail