Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Message from discussion Externals in Repository (again) (was Re: Perl 6 Summary for 2004-10-01 through 2004-10-17)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Robert  
View profile  
 More options Oct 19 2004, 5:06 am
Newsgroups: perl.perl6.internals
From: rsp...@pobox.com (Robert)
Date: Tue, 19 Oct 2004 02:06:13 -0700
Local: Tues, Oct 19 2004 5:06 am
Subject: Externals in Repository (again) (was Re: Perl 6 Summary for 2004-10-01 through 2004-10-17)
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


    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2010 Google