I understand Dan's view that parrot should be 100% self contained, but I
really think its silly to inline CPAN modules into our CVS repository.
I have a compromise solution, which might satisfy Dan.
1. I create a new parrot-external-dependencies CVS repository. All
external dependencies that Dan will not allow to be external go here.
2. I setup some CVS magic, so 'co parrot' does the right thing and puts
all thee things from the parrot-external-dependencies directory into a
'externals' directory or something.
2a. There will also be a parrot-base CVS module which will be the
contents of the existing one.
Actually, this can be expanded to have several different checkoutable
things in CVS:
maybe..
parrot-base
parrot-external-perl
parrot-external-icu
parrot-languages
and one
parrot
(or Parrot, if we want to be like the mozilla folks)
that gets them all.
There is another compromise, that says: "CVS shouldn't have CPAN
modules. But the release process for packages will include the tar
inside the tar."
Thoughts?
-R
Joshua Gatcomb accidentally introduced a dependency
on
Config::IniFiles. Since it is implemented in pure
perl he offered to
add it to the repository. Warnock applies.
In the note offering to fix it, I also listed numerous
other scripts with non-core dependencies. Dan, in
IRC, indicated that they all should have tickets on
them. Before fixing parrotbench.pl with one of the
following solutions:
1. inline Config::IniFiles with the author's
permission
2. Use some other core module if possible
3. Roll my own
4. Revert back to previous non-module version
