|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
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
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
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
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're nice
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's a
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 the
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
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.
That has
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 bother
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
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
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 (e.g.
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 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 allowed by
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 ported
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 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 much
--- 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 Foo (probably
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 possibility of
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 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 alpha/beta
[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
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
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
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 no
26 matches
Mail list logo
