On Thu, Jun 13, 2002 at 12:00:13AM +0300, [EMAIL PROTECTED] wrote:
>
> |On 6/4/02 12:22 PM, David Wheeler wrote:
> |> I think that if we can agree to forego backwards compatibility, we might
> |> also be in a better position to set up a CP6AN with much better quality
> |> control. All of the most
|On 6/4/02 12:22 PM, David Wheeler wrote:
|> I think that if we can agree to forego backwards compatibility, we might
|> also be in a better position to set up a CP6AN with much better quality
|> control. All of the most important modules will be ported very quickly
|> (e.g., the DBI), and a l
For the record, you will hear no disagreement from me. I recognize that
this is a HARD problem. Nonetheless, I think it's an important one, and
solving it (even imperfectly, by only supporting well-defined platforms)
would be a major coup.
--Josh
At 23:31 on 06/05/2002 BST, Nicholas Clark
> For the record, you will hear no disagreement from me. I recognize that
> this is a HARD problem. Nonetheless, I think it's an important one, and
> solving it (even imperfectly, by only supporting well-defined platforms)
> would be a major coup.
I'd like to take that even further: just suppor
On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote:
>
> Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See
> also debian's apt-get.
>
> Which brings me to my pet peeve- I think it's time to start doing binary
> packaging in CPAN, for those who don't want to bothe
At 12:55 AM -0400 6/5/02, Josh Wilmes wrote:
>Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See
>also debian's apt-get.
>
>Which brings me to my pet peeve- I think it's time to start doing binary
>packaging in CPAN, for those who don't want to bother with compilation.
>
>Tha
At 2:59 PM -0400 6/5/02, Steve Simmons wrote:
>My seat of the pants number say our current tools (which use DBI to
>access databases) spend about as 10% of their CPU and wall clock time
>in compilation. This is measured by deliberately running the tools
>with an error (bad switch) vs running it c
On 6/5/02 2:59 PM, Steve Simmons wrote:
> Sticking just to the disk-intensive issue for a moment --
> [...]
> With the new one, we seem to have agreed that `most recent' will be
> used, not `first found'. That means that every tree must be probed,
> and probed with globs or sub-searches to match
On Tue, Jun 04, 2002 at 04:15:02PM -0400, John Siracusa wrote in
response to me:
> > Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state.
> . . .
> Nah, I think it's useful to be able to upload "unstable" versions to 6PAN to
> get the widest possible audience of testers. It'
On Tue, Jun 04, 2002 at 01:11:58PM -0700, David Wheeler wrote:
> On 6/4/02 12:59 PM, "Steve Simmons" <[EMAIL PROTECTED]> claimed:
>
> > Actually, for 6PAN I think they should have to pass. And maybe we
> > need a bug submission setup, and status checks, and . . . OK, OK, I'll
> > stop now. They
Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See
also debian's apt-get.
Which brings me to my pet peeve- I think it's time to start doing binary
packaging in CPAN, for those who don't want to bother with compilation.
That has interesting implications for how we deal wi
On Tue, 4 Jun 2002, Luke Palmer wrote:
> On Tue, 4 Jun 2002, Miko O'Sullivan wrote:
>
> > No configuration files (.e.g .cpan) are necessary. However, you can use a
> > configuration file if you want tp indicate a .cpan-like file
> >
> >cpan --conf ~/.cpan load Date::EzDate
>
> What about n
On Tue, Jun 04, 2002 at 10:48:06PM -0600, Luke Palmer wrote:
> Hmm... I like it. It took me a good 6 months before I learned how to use
> CPAN. I don't see how your proposal is that different from:
>
> alias cpan='perl -MCPAN -e shell'
CPAN.pm already installs a cpan program for you that's ex
Hmm... I like it. It took me a good 6 months before I learned how to use
CPAN. I don't see how your proposal is that different from:
alias cpan='perl -MCPAN -e shell'
But I get the idea. Someone (well, you've inspired me now, so I) could
write a perl5 equivilent, because command line is qui
[This seems like a good time to post something that's been on my mind for
some time.]
SUMMARY
The world needs a really easy CPAN client. Here's one design for such a
thing.
DETAILS
A few brief philosphical points:
1) People like languages that have tons of built-in
doohickeys. See PH
On 6/4/02 3:59 PM, Steve Simmons wrote:
>> : 1c. Distinctions like "alpha", "beta", and "stable" need to be made
>> : according to some convention (a la $VERSION...perhaps $STATUS?)
>>
>> Can probably burn that bridge when we get to it.
>
> Frankly, I'd argue that nothing in 6PAN ought to be in
On 6/4/02 12:59 PM, "Steve Simmons" <[EMAIL PROTECTED]> claimed:
>> It shouldn't be required that all tests pass, however. A statement showing
>> what platforms they pass on and what platforms they don't at the top of the
>> download page would be good enough. But the tests have got to be there.
On Tue, Jun 04, 2002 at 12:59:38PM -0400, John Siracusa wrote:
> In the spirit of Simon's desire to see "radical changes" when appropriate, I
> propose the following high-level goals for 6PAN . . .
> 1. Multiple versions of the same module may be installed on a single system
> with no possibilit
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> :
> : 1a. Modules may be "use"-ed in several ways (syntax ignored for
> now):
> :
> : # Note "...installed on this system" is implied at the end
> : # of each of the following descriptions
> :
> : "Use the latest stable version of module
On 6/4/02 1:26 PM, Larry Wall wrote:
> : Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of
> : this effort? Do we even have a vague idea of the requirements? Or does
> : everyone think CPAN (and module distribution/installation in general) as it
> : exists now it pretty
On 6/4/02 10:21 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed:
> Well, there are already "suggested" conventions for version number formats.
>
> Anyway, CPAN is supposed to be organized! It's not a free-for-all dumping
> ground for modules. Let the version numbering and API anarchists use
>
On Tue, 4 Jun 2002, John Siracusa wrote:
: On 6/4/02 12:22 PM, David Wheeler wrote:
: > I think that if we can agree to forego backwards compatibility, we might
: > also be in a better position to set up a CP6AN with much better quality
: > control. All of the most important modules will be porte
On 6/4/02 1:11 PM, David Wheeler wrote:
> On 6/4/02 9:59 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed:
>> 1b. 6PAN modules comply with an informal contract to maintain
>> backward-compatibility within all N.MM versions, where N is constant. In
>> other words, incompatible API changes are only
On 6/4/02 12:34 PM, Steve Simmons wrote:
> As for CPAN . . . don't get me started. CPAN is a blessing, but has
> become a curse as well. It's contents need to be razed to the ground
> and better/more conistant rules set up for how to do installations
> into and out of the standard trees. If you
On 6/4/02 9:59 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed:
> 1b. 6PAN modules comply with an informal contract to maintain
> backward-compatibility within all N.MM versions, where N is constant. In
> other words, incompatible API changes are only allowed by incrementing the
> "major version
On 6/4/02 12:22 PM, David Wheeler wrote:
> I think that if we can agree to forego backwards compatibility, we might
> also be in a better position to set up a CP6AN with much better quality
> control. All of the most important modules will be ported very quickly
> (e.g., the DBI), and a lot of the
26 matches
Mail list logo
