[EMAIL PROTECTED] (Dan Sugalski) writes:
[...]
It's an ongoing fight between the go get the libs and install them
folks and the self-contained distribution folks. I'm in the latter
category. :)
As Larry said, self-contained is good for users. For developers
(and CVS) go get the libs is
At 4:45 PM +0100 3/4/04, Michael Scott wrote:
On 4 Mar 2004, at 15:51, Dan Sugalski wrote:
[...]
I'd like to remove non-modified, non-parrot Perl modules from lib
and install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more
At 11:49 AM -0800 3/4/04, Robert Spier wrote:
I'd like to remove non-modified, non-parrot Perl modules from lib
and install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more than it's going to run apt-get on
systems that
On 6 Mar 2004, at 05:31, Robert Spier wrote:
[...]
The problem isn't today. It's the trend and next month, when
someone decides they need to add some other module, and has a
precedent to follow. Then, suddenly we end up with 30 different
modules included in our distribution, each one changed
On Mar 4, 2004, at 7:50 PM, Robert Spier wrote:
IMHO, the releases better include everything necessary to build the
application, within reason. Consistency and simplicity counts for a
lot.
Why create headaches we don't need?
within reason. Thats where we're way off right now.
Let's keep a bit
within reason. Thats where we're way off right now.
Let's keep a bit of perspective here. The non-Parrot:: contents of lib
accounts for only 4.6% of the non-ICU content (and only 1.5% if you
count ICU in the total size). It's difficult to see that as
unreasonable, or as bloat.
The
On 7 Feb 2004, at 00:53, Michael Scott wrote:
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote:
- icu
- lib/Test/*
- lib/Pod/*
are all standard thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are gonna copying existing wheels, so
I'd
vote for just removing all that from
At 3:40 PM +0100 3/4/04, Michael Scott wrote:
On 7 Feb 2004, at 00:53, Michael Scott wrote:
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote:
- icu
- lib/Test/*
- lib/Pod/*
are all standard thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are gonna copying existing
On 4 Mar 2004, at 15:51, Dan Sugalski wrote:
[...]
I'd like to remove non-modified, non-parrot Perl modules from lib and
install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more than it's going to run apt-get on
systems
On Mar 4, 2004, at 7:45 AM, Michael Scott wrote:
On 4 Mar 2004, at 15:51, Dan Sugalski wrote:
[...]
I'd like to remove non-modified, non-parrot Perl modules from lib and
install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any
I'd like to remove non-modified, non-parrot Perl modules from lib
and install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more than it's going to run apt-get on
systems that support it. We either provide it or do
On Thu, Mar 04, 2004 at 03:40:27PM +0100, Michael Scott wrote:
: I'd like to remove non-modified, non-parrot Perl modules from lib and
: install them via CPAN.pm. I have a version here which works, but I
: remember from experience it can be tricky to set up CPAN.pm to work
: behind firewalls,
Dan Sugalski [EMAIL PROTECTED] wrote:
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more than it's going to run apt-get on
systems that support it. We either provide it or do without.
What about ICU. There is already a new version pending
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more than it's going to run apt-get on
systems that support it. We either provide it or do without.
What about ICU. There is already a new version pending (again).
Since we haven't actually
There's no reason to include large, independently maintained modules
like Pod::Simple in the parrot CVS tree and tarball. It just turns
into a maintenance nightmare, should we ever start modifying these
things.
[...]
I don't understand why you are insisting on including these
The determinism seems perhaps worth the bloat. It's quite localize
bloat after all.
I disagree.
We _want_ a heterogeneous environment -- a homogeneous environment
doesn't exist in the real world -- most of your concerns were with
tracking down the issues. Since we have parrotbug now (or real
At this point in the development cycle you can certainly make such
arguments (although I would tend to fall on the side of consistency
myself, at least for things that really Don't Matter in the grand scheme
of things, such as POD modules).
But once we start expecting people in the real world
But once we start expecting people in the real world to compile this thing
on their boxes in order to install perl, it would be extremely foolish to
make them manually download and install perl6 + parrot + icu + perl5 +
cpan modules 1 through 10, all from different sources.
Try building
Robert Spier [EMAIL PROTECTED] wrote:
Pod::Simple is relatively easy to subclass. And Sean is pretty
receptive to changes.
[ more referenced source inside ]
- icu
- lib/Test/*
- lib/Pod/*
are all standard thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are gonna
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote:
- icu
- lib/Test/*
- lib/Pod/*
are all standard thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are gonna copying existing wheels, so
I'd
vote for just removing all that from CVS.
yep
All non-trivial packages have some
Suppose I could make a few changes to Pod-Simple, then our problem
would be solved.
But, being serious, say I'd decided to use Template-Toolkit, it would
never have occurred to me to shove all of that in CVS. It always
surprised me a that ICU was there, rather than just what was needed to
get
Suppose I could make a few changes to Pod-Simple, then our problem
would be solved.
Pod::Simple is relatively easy to subclass. And Sean is pretty
receptive to changes.
never have occurred to me to shove all of that in CVS. It always
surprised me a that ICU was there, rather than just
Ah, ok, my bad then. I'd just assumed that, apart from any need for
modification, the other things were there simply to save having to tell
everyone to go off and get them. I don't intend to change Pod-Simple if
I can possibly help it, so it's ok by me to delete lib/Pod, if that's
the
23 matches
Mail list logo
