Re: 6PAN (was: Half measures all round)

2002-06-12 Thread Tim Bunce

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 important modules will be ported very quickly
> |> (e.g., the DBI),

Actually I doubt that complex extensions with lots of XS/C code
will get ported "very quickly" since the work involved may be
considerable.

That's one of the reasons I've put so much effort into making
DBI::PurePerl a viable tool. It'll automatically give people a
working Perl6 DBI (for pure-perl drivers) as soon as there's a
working perl5-to-perl6 translator.

Tim.



Re: 6PAN (was: Half measures all round)

2002-06-12 Thread raptor





|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 cruft will be left to die (at least from
|> the Perl 6 perspective).
|
|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 okay, and just needs some tweaks to work with Perl
|6 code?  I really hope that's not the case! :)

]- I think there is CPANTS initiative underway which may be will solve some of 
]problems of the current CPAN... there was even a write-up on www.perl.com about it ...



Re: 6PAN (was: Half measures all round)

2002-06-06 Thread Josh Wilmes



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 <[EMAIL PROTECTED]> wrote:

> 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 with compilation.
> > 
> > That has interesting implications for how we deal with paths, but still, I 
> > think it's worthwhile.
> > 
> > Of course you would want to support source as well, but having binary 
> > available for those who want it just seems like a darn good idea.
> 
> OK. Say I want binaries for my 3 boxes:
> 
> On Bagpuss /usr/local/bin/perl -v says:
> 
> This is perl, v5.8.0 built for armv4l-linux
> (with 1 registered patch, see perl -V for more detail)
> 
> but you had better actually build that with -v3 flags on your ARM compiler
> because my machine's hardware can't cope with the v4 instructions on the CPU
> 
> On Thinking-Cap /usr/local/bin/perl -v says:
> 
> This is perl, version 5.004_05 built for i386-freebsd
> 
> Copyright 1987-1998, Larry Wall
> 
> 5.004 is officially still supported, and some modules do build on 5.004
> 
> [Third box, Marvellous-Mechanical-Mouse-Organ is an SGI Indy and doesn't
> doesn't want to power up for some reason, probably because it's been off
> for about 12 months]
> 
> I presume you're going to suggest that they are too obscure for binary CPAN
> to support them. So limit things to the most recent perl. But having
> experimented with trying to ship 5.8.0-RC1 between FreeBSD versions, there
> are sufficient changes between libc on 4.4 STABLE and 4.5 STABLE such that
> you can't run a binary compiled on 4.5 on a 4.4 box due to missing symbols.
> So you're starting to enter version compatibility nightmare.
> 
> And if you have module needing a C++ compiler, are you going to ship your
> x86 linux binaries using RedHat's 2.96, or a real gcc?
> 
> And are you doing dependencies, or are you interfacing with the OS package
> manager? And if you're not interfacing, but you are adding modules to the
> OS perl, then what do you do if one of your dependency modules is already
> there? Do you just go "oh good", have binary CPAN say nothing, and then
> hope that the OS packaging system doesn't remove the dependency module from
> under you?
> 
> I believe that binary CPAN would have problems that scale as the number
> of OS subversions that binary CPAN would try to support.
> 
> This may sound rather negative, but it basically means that I'm feeling
> sufficiently pessimistic that I don't think there are reasonable solutions
> to the problems. However, that's only my opinion, and others' will differ.
> 
> On the other hand, I think the idea of multiple platforms automatic CPAN
> testing is a very good idea.
> 
> Nicholas Clark
> -- 
> Even better than the real thing:  http://nms-cgi.sourceforge.net/





Re: 6PAN (was: Half measures all round)

2002-06-05 Thread Miko O'Sullivan

> 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 supporting Win32 binaries would be
a major coup.  Very few windows users can compile, but a much more
significant percent of Un*x users can.

A few more ways to address issues of multi-platform (my favorite is at the
end):

- Divide and conquer: design the 6PAN so that individuals and small groups
can set up their own binary specific distribution sites.  One person might
decide to set up a Win32 distribution site, another a Mac distribution site.
They can all register on the central 6PAN server.  Users can then choose
which distributions they prefer in general.

- Unit testing: with binaries it becomes more imperative that downloaded
modules are rigourously tested.  Unit tests should be distributed with
modules, and download clients should have a way of saving errors and (if the
user givesd permission) sending them back to the developer.

- My favorite: don't do binaries.  With bytecode Pure Perl makes all the
more sense.  I'm not saying binaries should be prohibited, but the culture
should steer away from them.




Re: 6PAN (was: Half measures all round)

2002-06-05 Thread Nicholas Clark

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 with compilation.
> 
> That has interesting implications for how we deal with paths, but still, I 
> think it's worthwhile.
> 
> Of course you would want to support source as well, but having binary 
> available for those who want it just seems like a darn good idea.

OK. Say I want binaries for my 3 boxes:

On Bagpuss /usr/local/bin/perl -v says:

This is perl, v5.8.0 built for armv4l-linux
(with 1 registered patch, see perl -V for more detail)

but you had better actually build that with -v3 flags on your ARM compiler
because my machine's hardware can't cope with the v4 instructions on the CPU

On Thinking-Cap /usr/local/bin/perl -v says:

This is perl, version 5.004_05 built for i386-freebsd

Copyright 1987-1998, Larry Wall

5.004 is officially still supported, and some modules do build on 5.004

[Third box, Marvellous-Mechanical-Mouse-Organ is an SGI Indy and doesn't
doesn't want to power up for some reason, probably because it's been off
for about 12 months]

I presume you're going to suggest that they are too obscure for binary CPAN
to support them. So limit things to the most recent perl. But having
experimented with trying to ship 5.8.0-RC1 between FreeBSD versions, there
are sufficient changes between libc on 4.4 STABLE and 4.5 STABLE such that
you can't run a binary compiled on 4.5 on a 4.4 box due to missing symbols.
So you're starting to enter version compatibility nightmare.

And if you have module needing a C++ compiler, are you going to ship your
x86 linux binaries using RedHat's 2.96, or a real gcc?

And are you doing dependencies, or are you interfacing with the OS package
manager? And if you're not interfacing, but you are adding modules to the
OS perl, then what do you do if one of your dependency modules is already
there? Do you just go "oh good", have binary CPAN say nothing, and then
hope that the OS packaging system doesn't remove the dependency module from
under you?

I believe that binary CPAN would have problems that scale as the number
of OS subversions that binary CPAN would try to support.

This may sound rather negative, but it basically means that I'm feeling
sufficiently pessimistic that I don't think there are reasonable solutions
to the problems. However, that's only my opinion, and others' will differ.

On the other hand, I think the idea of multiple platforms automatic CPAN
testing is a very good idea.

Nicholas Clark
-- 
Even better than the real thing:http://nms-cgi.sourceforge.net/



Re: 6PAN (was: Half measures all round)

2002-06-05 Thread Dan Sugalski

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 interesting implications for how we deal with paths, but still, I
>think it's worthwhile.

The biggest issues with binaries are relocatability (which is a 
problem on some OSes), build options, compiler compatibility, and 
size.

Size is the biggest obvious problem--there are a lot of modules with 
C code, and object code is generally larger than the C it came from, 
often by an order of magnitude or two. Multiply that by the potential 
number of OS/compiler/perl build options and you get a number 
that's rather large.

The rest are just complicated icing on the cake.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
Perl class: stemsystems.com/class teddy bears get drunk



Re: 6PAN (was: Half measures all round)

2002-06-05 Thread Dan Sugalski

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 correctly and comparing
>the times.  Go to a module/version/release seach pattern and a
>ten-fold minimum increase in serach time . . . and you double the tool
>run times.  That's intolerable in our environment.  I recently spent
>a solid month peeling 9 seconds of per-tool overhead down to 1 second,
>getting a documented(!) savings of 16.25 hours *per week* in our
>operations group.  The prospect of losing that time again with perl6
>is, er, not acceptable.  Again, this argues towards indexes.

Nah. It argues for precompilation and a faster engine, both of which 
you'll get. :)
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk



Re: 6PAN (was: Half measures all round)

2002-06-05 Thread John Siracusa

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 various author,
> version, $RELEASE, etc stuff.
> [...]
> I recently spent a solid month peeling 9 seconds of per-tool overhead down to
> 1 second, getting a documented(!) savings of 16.25 hours *per week* in our
> operations group.  The prospect of losing that time again with perl6 is, er,
> not acceptable.  Again, this argues towards indexes.

More generally, I'd just call it caching.  This can be done in many ways:
cached "flattened" bundle files, traditional indexes, or even simply another
module that does some (or all) of this for you, when needed, by augmenting
the "use" implementation with its own cached information:

use Module::Cache;
use Foo; # subsequent "use"s are faster now! :)
use Bar;
...

There may be some bootstrapping issues, but so far everything in Perl 6
seems up for "user replacement/augmentation."  Why not "use" as well? :)
  
>>> The current perl module tree is pretty difficult for the average day to
>>> day scripter to comprehend.  I'd go even further and say that it's so
>>> complex as to be unmanagable.
>> 
>> Encapsulating by module would make the structure pretty easy to understand,
>> IMO.
> 
> Yes, that would help with the understanding.  It would not help with
> the search time overhead.

But that's fixable.  It's much harder to make an inherently confusing (but
"fast") on-disk organization "more understandable", IMO :)

-John




Re: 6PAN (was: Half measures all round)

2002-06-05 Thread Steve Simmons

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 lot easier than hosting
> it on a web site or whatever--for both the developer and the users.
  . . .

True, true.  You've convinced me.

> > . . . .  With (potentially) many modules having
> > the same name and multiple authors/versions, the current complexity of
> > the perl /lib tree could increase to the third power.  That gonna be
> > very disk-intensive for every frigging perl script that runs.
> 
> See my earlier framework/bundle suggestion.  I don't think it's that bad,
> disck-access-wise.

Sticking just to the disk-intensive issue for a moment --

Due to our judicious writing of modules, libraries, etc, we tend to have
a lot have relatively simple (less than 1000 lines) scripts that do quite
useful things for managing our network (sorry, can't talk about 'em --
proprietary software and all that sort of rot).  Each tool does a direct
use or require of about a half-dozen things, but our master modules and
libs grab quite a few more.  All in all I guestimate we're loading anywhere
from 30 to 100 modules per `simple' tool run.  With standard @INC plus
our two or three more, that's 8-10 directory trees that must be searched.

The current perl module naming schema means (essentially) one probe
per directory per package until the module is found.  Once it's found,
all is done.

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 various author,
version, $RELEASE, etc stuff.  Only once we know what's available can
we make an intelligent `most recent' decision.  At a minimum, with
10 items in @INC we have a tenfold increase in number of dir reads.
Then add in the checking for author, version, etc ... and we've
got to either embed the author/version/release data into the file
names (the horror, the horror) or open the individual modules and
read the author/version/release data from each one (the horrorer, the
horrorer).  This very strongly argues towards indexes.

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 correctly and comparing
the times.  Go to a module/version/release seach pattern and a
ten-fold minimum increase in serach time . . . and you double the tool
run times.  That's intolerable in our environment.  I recently spent
a solid month peeling 9 seconds of per-tool overhead down to 1 second,
getting a documented(!) savings of 16.25 hours *per week* in our
operations group.  The prospect of losing that time again with perl6
is, er, not acceptable.  Again, this argues towards indexes.

> > The current perl module tree is pretty difficult for the average day to
> > day scripter to comprehend.  I'd go even further and say that it's so
> > complex as to be unmanagable.
> 
> Encapsulating by module would make the structure pretty easy to understand,
> IMO.

Yes, that would help with the understanding.  It would not help with
the search time overhead.

> Disk space and RAM are cheap and getting cheaper.  Think about what you mean
> by "gigantic."  Anyone who exhausts memory by running 150 different versions
> of the Tk module at once deserves what they get ;)
> 
> > On the other hand, there's no reason that shared libs couldn't be stored in a
> > standard location and symlinked to.
> 
> Yes there is: sanity!  I think that's a foolish optimization.  It makes
> things much too fragile.  Stuff like that already drives me nuts in regular
> Unix OS/app installations.

I picked Tk as my example because it *cannot* work with multiple
versions of the shared libraries (the .so files, not the perl modules)
simultaneously.  Every window, every widget, every Ghu-knows-what down
to a fairly low level must reside in the same context.  If they don't,
subwindows don't get managed properly, widgets from version X can't be
attached to units from version Y, etc, etc.  The same is almost certianly
true of DBI modules, Gnome modules, and many others.  The 6PAN installation
tree and perl6 module builds must be able to deal with this issue.  If
they don't, then Larry's promise of the ability of simultaneous load is
only going to apply to pure perl modules.  But I don't think that's what
Larry means, and I don't think it's a restriction we *have* to live with.

Steve
-- 
STEP 4: PRACTICE THE RULE OF THREE: If an e-mail thread has gone back and
forth three times, it is time to pick up the phone.
  from the 12-Step Program for email addicts,
  http://www.time.com/time/columnist/taylor/article/0,9565,2

Re: 6PAN (was: Half measures all round)

2002-06-05 Thread Steve Simmons

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 ideas, but who bells the cat?  The again, if
> > Tim O'Reilly wants to fund me I'd be happy to do it.  :-)
> 
> On what platform(s)? Who's going to pay for the test bed for every possible
> combination of perl version, OS, various libraries, etc., etc.? I think that
> *requiring* that all tests pass is unrealistic.

Perhaps so, but I'd prefer to see this as a goal and fall short rather
than set our sights lower and achieve an empty success.

As for funding - well, one source has been mentioned above.  Another
might be the H/W vendors.  Suppose we modify the proposal to have a
list of systems on which the module has been known to pass (or fail)
self-test?  Get H/W and O/S donations from Sun, HP, etc, volunteer
labor to assemble a test framework, and then let people upload.  On
the web page for a given 6PAN module put a pass/fail indicator for
all the stuff that vendors have donated.  Vendor X wants to be on the
list?  Let 'em donate hardware, S/W, and (maybe eventually) something
towards overhead.

Hmmm, we may have a good idea here... 



Re: 6PAN (was: Half measures all round)

2002-06-05 Thread Josh Wilmes


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 with paths, but still, I 
think it's worthwhile.

Of course you would want to support source as well, but having binary 
available for those who want it just seems like a darn good idea.

Of course there would be issues of who's providing the binaries, how they 
are built, how external dependencies on third-party libraries are managed,
etc, but still, I think it's worth looking into.  It might not be a 
problem that's worth solving, in the end, but I think it's one worth 
giving serious thought to.

--Josh

At 23:38 on 06/04/2002 EDT, "Miko O'Sullivan" <[EMAIL PROTECTED]> wrote:

> [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 PHP and Java.
> 
>   2) Instead of a huge standard library, a really easy to use CPAN
>   client allows programmers to have the world of modules almost
>   as easily as built-in, and with the advantage of up-to-date-ness
>   and quantity.
> 
>   3) The current CPAN.pm isn't really easy to use. Now matter how
>   simple it may seem to the Perl Guru community, inexperienced
>   users find it intimidating to download CPAN modules.
>   Remember: beginners end up ruling the world.  See Microsoft.
> 
> Solution: a simple program that is called from the command line.  Here's a
> brief tour:
> 
> Download and install a module from CPAN. Loading a module also automatically
> loads its dependencies.
> 
>cpan load Date::EzDate
> 
> The command above would ask the user if they want to install using the
> current directory as the root of library tree, and is also mentions that if
> they want to specify another dir they can use this command:
> 
>cpan --lib ~/lib load Date::EzDate
> 
> Update a module.
> 
>cpan update Date::EzDate
> 
> Don't download dependencies:
> 
>cpan --dep 0 load Date::EzDate
> 
> Update all currently installed modules:
> 
>cpan update *
> 
> Update a namespace:
> 
>cpan update Date::*
> 
> Get help on using cpan:
> 
>cpan help
> 
> 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
> 
> Get from a particular FTP server
> 
>cpan --server cpan.idocs.com load Date::EzDate
> 
> By default, progress messages are kept to a minimum.  No more of those
> hundreds of lines of bewildering make messages.
> 
>cpan --lib ~/perllib load Date::EzDate
>finding server
>downloading module
>determining dependencies
>downloading dependencies
>installing
>done
> 
> Optional verbose mode
>cpan --verbose load Date::EzDate
>(hundreds of lines of lovely make messages)
> 
> Request particular operating system compilation (e.g. Win32)
> (usually not needed explicitly because cpan.pl will know which compilation
> to ask for)
> 
>cpan --compile win32 load Date::EzDate
> 
> Indicate latest development vs. latest stable
> 
>cpan --latest beta load Date::EzDate
> 
> Remove a module
>cpan remove Date::EzDate
> 
> 
> -
> Other Misc CPAN Ideas
> 
> - Authors don't need to indicate dependencies.  CPAN figures it out from the
> use's and require's.  CPAN will not accept modules that depend on other
> modules that aren't on CPAN.  (Yes, there might be a chicken and egg problem
> there, I'm sure we can find a solution.) This leads me to...
> 
> - Run-time dependencies: Dependencies can be indicated explicitly with
> something like this:
> 
>  use Dependency Date::Language::French;
> 
> - CPAN conformity: All modules served from CPAN must meet certain
> specifications.  They must include a version, POD, license statement, and
> probably other meta-info.  The meta-info would be standardized so that the
> system could tell that the module conforms.
> 
> - Automated load balancing: cpan.perl.org doesn't have to pay for the
> bandwidth of the whole world. cpan.pl should recognize a command from
> CPAN.org to redirect to another server.
> 
> - 6pan.org: The domain name 6pan.org is available as of this writing. Larry,
> are you planning on saying "6PAN" enough to merit somebody registering
> 6pan.org?
> 
> 





Re: 6PAN (was: Half measures all round)

2002-06-04 Thread Dave Storrs



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 configuration file if ~/.6pan's not there, and ~/.6pan if it
> is.

Personally, I'd like it to:

1) work just fine without a config file,
2) if I specify one, it uses that,
3) if I don't specify one, but the default exists, it uses that
4) if it uses a config file (specified or default) it shows the
full path to what it's using, so that I have a chance of detecting Trojans
and typos if I'm paying attention (I don't need or want it to ask for
confirmation, just show a message and maybe 'sleep 1' before continuing)


> > - Authors don't need to indicate dependencies.  CPAN figures it out from the
> > use's and require's.  CPAN will not accept modules that depend on other
> > modules that aren't on CPAN.  (Yes, there might be a chicken and egg problem
> > there, I'm sure we can find a solution.) This leads me to...
>

Having it figure out the dependencies is definitely a major plus.
As to how to solve the chicken-and-egg...just provide a way to upload
multiple separate modules simultaneously.


Dave




Re: 6PAN (was: Half measures all round)

2002-06-04 Thread Michael G Schwern

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 exactly that.

schwern@blackrider:/usr/local/src/CPAN/CPAN-1.61$ cat cpan 
#!/usr/bin/perl

use CPAN;
shell;


As for the rest of the message, this all seems to already exist, in one
form or another, in the CPAN shell or CPANPLUS shell.  If you want to see a
better CPAN shell, don't wait for Perl 6!  Help the CPANPLUS folks out now!
http://cpanplus.sourceforge.net/


> But I get the idea.  Someone (well, you've inspired me now, so I) could 
> write a perl5 equivilent, because command line is quite nice.  I'll see 
> how it flies with my next class.
> 
> More comments below.
> 
> On Tue, 4 Jun 2002, Miko O'Sullivan wrote:
> 
> > [This seems like a good time to post something that's been on my mind for
> > some time.]
> 
> Sure. It's been pretty dull around here.
> 
> > DETAILS
> > 
> > A few brief philosphical points:
> > 
> >   1) People like languages that have tons of built-in
> >   doohickeys. See PHP and Java.
> 
> See Perl 5 (though PHP and Java far exceed it, in doohickeys)
> 
> >   2) Instead of a huge standard library, a really easy to use CPAN
> >   client allows programmers to have the world of modules almost
> >   as easily as built-in, and with the advantage of up-to-date-ness
> >   and quantity.
> 
> Indeed. And it should be _really_ easy to install to a different source 
> tree and have Perl use it. I want more modules on systems I don't 
> administrate, and asking for them is a pain.
> 
> > The command above would ask the user if they want to install using the
> > current directory as the root of library tree, and is also mentions that if
> > they want to specify another dir they can use this command:
> > 
> >cpan --lib ~/lib load Date::EzDate
> 
> Hmm... yeah, I think that's as easy as library root's gonna get. I like 
> C better than C, though.




-- 
This sig file temporarily out of order.



Re: 6PAN (was: Half measures all round)

2002-06-04 Thread Luke Palmer

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 quite nice.  I'll see 
how it flies with my next class.

More comments below.

On Tue, 4 Jun 2002, Miko O'Sullivan wrote:

> [This seems like a good time to post something that's been on my mind for
> some time.]

Sure. It's been pretty dull around here.

> DETAILS
> 
> A few brief philosphical points:
> 
>   1) People like languages that have tons of built-in
>   doohickeys. See PHP and Java.

See Perl 5 (though PHP and Java far exceed it, in doohickeys)

>   2) Instead of a huge standard library, a really easy to use CPAN
>   client allows programmers to have the world of modules almost
>   as easily as built-in, and with the advantage of up-to-date-ness
>   and quantity.

Indeed. And it should be _really_ easy to install to a different source 
tree and have Perl use it. I want more modules on systems I don't 
administrate, and asking for them is a pain.

> The command above would ask the user if they want to install using the
> current directory as the root of library tree, and is also mentions that if
> they want to specify another dir they can use this command:
> 
>cpan --lib ~/lib load Date::EzDate

Hmm... yeah, I think that's as easy as library root's gonna get. I like 
C better than C, though.


> Don't download dependencies:
> 
>cpan --dep 0 load Date::EzDate

So, what's the difference between --dep 2 and --dep 3? Is that depth or 
something? Or max number?

> Update all currently installed modules:
> 
>cpan update *

Oh, if only shells could DWIM... Naturally this would do cpan update and 
then every file in the current directory. To remedy this you have to do 
some awful thing like:

cpan update \*
or
cpan update '*'

Maybe 'all' would serve the purpose better.

> Update a namespace:
> 
>cpan update Date::*

I like that idea a lot.

> Get help on using cpan:
> 
>cpan help

Err, howsabout the GNU way...

cpan --help

> 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 configuration file if ~/.6pan's not there, and ~/.6pan if it 
is.

> By default, progress messages are kept to a minimum.  No more of those
> hundreds of lines of bewildering make messages.
> 
>cpan --lib ~/perllib load Date::EzDate
>finding server
>downloading module
>determining dependencies
>downloading dependencies
>installing
>done

We could just go with the idiomatic "don't say anything unless it's bad." 
I've developed a taste for that.  Perhaps this is better for the default 
and you can enable quiet through ~/.6pan.

> -
> Other Misc CPAN Ideas
> 
> - Authors don't need to indicate dependencies.  CPAN figures it out from the
> use's and require's.  CPAN will not accept modules that depend on other
> modules that aren't on CPAN.  (Yes, there might be a chicken and egg problem
> there, I'm sure we can find a solution.) This leads me to...

What about version discrepancies?   I guess that can come from the 
Cs.

> - Automated load balancing: cpan.perl.org doesn't have to pay for the
> bandwidth of the whole world. cpan.pl should recognize a command from
> CPAN.org to redirect to another server.

Definitely. I like on-6pan mirrors better than on-client mirrors.


About the name 6PAN... I mean it reads well, but does it mean anything? 
The, er, 6 Perl Archive Network?  

RCPAN? Really Comprehensive Perl Archive Network?  :)

Or just PAN?

I got nuthin'.

Luke




Re: 6PAN (was: Half measures all round)

2002-06-04 Thread Miko O'Sullivan

[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 PHP and Java.

  2) Instead of a huge standard library, a really easy to use CPAN
  client allows programmers to have the world of modules almost
  as easily as built-in, and with the advantage of up-to-date-ness
  and quantity.

  3) The current CPAN.pm isn't really easy to use. Now matter how
  simple it may seem to the Perl Guru community, inexperienced
  users find it intimidating to download CPAN modules.
  Remember: beginners end up ruling the world.  See Microsoft.

Solution: a simple program that is called from the command line.  Here's a
brief tour:

Download and install a module from CPAN. Loading a module also automatically
loads its dependencies.

   cpan load Date::EzDate

The command above would ask the user if they want to install using the
current directory as the root of library tree, and is also mentions that if
they want to specify another dir they can use this command:

   cpan --lib ~/lib load Date::EzDate

Update a module.

   cpan update Date::EzDate

Don't download dependencies:

   cpan --dep 0 load Date::EzDate

Update all currently installed modules:

   cpan update *

Update a namespace:

   cpan update Date::*

Get help on using cpan:

   cpan help

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

Get from a particular FTP server

   cpan --server cpan.idocs.com load Date::EzDate

By default, progress messages are kept to a minimum.  No more of those
hundreds of lines of bewildering make messages.

   cpan --lib ~/perllib load Date::EzDate
   finding server
   downloading module
   determining dependencies
   downloading dependencies
   installing
   done

Optional verbose mode
   cpan --verbose load Date::EzDate
   (hundreds of lines of lovely make messages)

Request particular operating system compilation (e.g. Win32)
(usually not needed explicitly because cpan.pl will know which compilation
to ask for)

   cpan --compile win32 load Date::EzDate

Indicate latest development vs. latest stable

   cpan --latest beta load Date::EzDate

Remove a module
   cpan remove Date::EzDate


-
Other Misc CPAN Ideas

- Authors don't need to indicate dependencies.  CPAN figures it out from the
use's and require's.  CPAN will not accept modules that depend on other
modules that aren't on CPAN.  (Yes, there might be a chicken and egg problem
there, I'm sure we can find a solution.) This leads me to...

- Run-time dependencies: Dependencies can be indicated explicitly with
something like this:

 use Dependency Date::Language::French;

- CPAN conformity: All modules served from CPAN must meet certain
specifications.  They must include a version, POD, license statement, and
probably other meta-info.  The meta-info would be standardized so that the
system could tell that the module conforms.

- Automated load balancing: cpan.perl.org doesn't have to pay for the
bandwidth of the whole world. cpan.pl should recognize a command from
CPAN.org to redirect to another server.

- 6pan.org: The domain name 6pan.org is available as of this writing. Larry,
are you planning on saying "6PAN" enough to merit somebody registering
6pan.org?





Re: 6PAN (was: Half measures all round)

2002-06-04 Thread John Siracusa

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 state.
> An author could make a package available that was in that condition,
> but it shouldn't be uploaded to 6PAN.  Once one has that restrition,
> $STATUS isn't really needed.  The adventurous will upload the alpha
> code from the author and install it into the 6PAN tree by specifying some
> sort of `force' flag.  Thereafter, our adventurere is on his own.

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 lot easier than hosting
it on a web site or whatever--for both the developer and the users.

Obviously the 6PAN shell would install "latest stable" by default, but
interested parties could get a glimpse of the future if they wanted, and
with no harm done to existing code.

Also think about the ramp-up to the first stable release.  Users may want to
try out all the pre-stable versions because they're better than nothing,
even if they understand that there I no "API contract" until the first
stable release.

> On Tue, Jun 04, 2002 at 11:13:53AM -0700, Austin Hastings wrote:
>> The following examples of font names are derived from the screen fonts
>> shipped with the X Consortium distribution.
>> 
>> Charter 12 pt  ...
>> -Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-IO8859-1
>> Charter Bold 12 pt ...
>> -Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1
>> Charter Bold Italic 12 pt  ...
>> -Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1
>> Charter Italic 12 pt   ...
>> -Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1
> . . .
> 
> I was about to run screaming from the room until reading the item a bit
> closer.

No no, you should still run screaming :)

> My current understanding (my hope) is that just saying
> 
>   use foo;
> 
> always gets you the latest foo.  With (potentially) many modules having
> the same name and multiple authors/versions, the current complexity of
> the perl /lib tree could increase to the third power.  That gonna be
> very disk-intensive for every frigging perl script that runs.

See my earlier framework/bundle suggestion.  I don't think it's that bad,
disck-access-wise.

> The current perl module tree is pretty difficult for the average day to
> day scripter to comprehend.  I'd go even further and say that it's so
> complex as to be unmanagable.

Encapsulating by module would make the structure pretty easy to understand,
IMO.

> In re putting everything for a given module into a given directory --
> it's a good thought, but I foresee problems with shared libraries
> (.so files).  With a gigantic module like the Tk:: core, you don't always
> want multiple copies of each shared lib for each Tk:: version.   It just
> ain't gonna fly.

Disk space and RAM are cheap and getting cheaper.  Think about what you mean
by "gigantic."  Anyone who exhausts memory by running 150 different versions
of the Tk module at once deserves what they get ;)

> On the other hand, there's no reason that shared libs couldn't be stored in a
> standard location and symlinked to.

Yes there is: sanity!  I think that's a foolish optimization.  It makes
things much too fragile.  Stuff like that already drives me nuts in regular
Unix OS/app installations.

-John




Re: 6PAN (was: Half measures all round)

2002-06-04 Thread David Wheeler

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.
> 
> 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 ideas, but who bells the cat?  The again, if
> Tim O'Reilly wants to fund me I'd be happy to do it.  :-)

On what platform(s)? Who's going to pay for the test bed for every possible
combination of perl version, OS, various libraries, etc., etc.? I think that
*requiring* that all tests pass is unrealistic.

Regards,

David

-- 
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]





Re: 6PAN (was: Half measures all round)

2002-06-04 Thread Steve Simmons

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 conflicts.  That means no conflicts of any kind,
> whether it be in Perl code, XS-ish stuff, private shared libs, etc.

Larry has stated this as a goal, and in this thread on Tue, Jun 04,
2002 at 10:26:22AM -0700, Larry Wall wrote:

> Yes, I'm already on record that multiple installed versions will
> coexist peacably, certainly on disk, and to the extent that they can
> in memory.  We can't stop two versions of a module from fighting over a
> shared resource, for instance . . .

And that's an issue that needs to be resolved -- modules are going to
have to be able to test for each others state of being loaded and have
some mechanisms to disambiguate and defer to each other.  I won't go
down the sytactic rathole of what *that* entails, just noting it as an
issue.

Back to John S:

> : 2. Module packaging, expansion, and installation only requires a working
> : install of Perl 6 (unless the module contains non-Perl code, such as C,

> 3. Module removal should be as easy as installation.

Yes, yes.

> 1a. Modules may be "use"-ed in several ways (syntax ignored for now):

I addressed a few of these in RFC78 and quite a few more in an as-yet
unpublished rewrite of it; Larry mentioned a line or two of syntax in
a recent email that's not terribly dissimilar.

All the things you specify are relatively easy in the perl world.  It's
mapping them into filenames and directories that @INC can use that
gets, er, interesting.  However . . .

> 1b. 6PAN modules comply with an informal contract to maintain
> backward-compatibility within all N.MM versions, where N is constant. . .

IMHO it should be a stated requirement, just as one needs a Makefile.PL.
And while person's tweak is another persons incompatible blotch, we
ultimately have to defer to `in the opinion of the author.'


On Tue, Jun 04, 2002 at 10:11:40AM -0700, David Wheeler responds to
Johns stuff above:

> This might be asking too much -- it's not very perlish, in the sense of
> TIMTOWTDI. It might make sense for DKs, but different people may want to use
> the conventions their comfortable with. Perl is there for you to create
> applications (and APIs) the way you want, not the way the gods demand.

I must respectfully disagree.  Perl has rules, and strict ones -- and
more than just the syntax and the semantics.  Anyone can *change* perls
syntax, but they have to get buy-in from a fairly large and conservative
community to get it incorporated into perl.  Why should we not be as
careful about 6PAN?

We could take this a step further -- let CPAN be the perl equivelent of
Sourceforge, but hold 6PAN to a higher standard.  TIMTOWTDI.

> One thing I think is as important -- or perhaps more important -- is to
> enforce the presence of unit tests. There are a lot of modules on the CPAN
> that have no tests, and most of them suffer for it.

Yes, but . . .

> 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.

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 ideas, but who bells the cat?  The again, if
Tim O'Reilly wants to fund me I'd be happy to do it.  :-)

On Tue, Jun 04, 2002 at 01:21:26PM -0400, John Siracusa wrote on
the same thread:

> Heh, I was going to suggest that new minor-version 6PAN submissions
> automatically have all the earlier minor-version test suites run against
> them before allowing them to go into the archive... :)

Yep, that too.  Which means . . .

On Tue, Jun 04, 2002 at 10:57:15AM -0700, David Wheeler wrote:
> On 6/4/02 10:21 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed:

> Hmmm...perhaps as a warning:
> 
>   All regression tests not passed. Do you still want to upload this module?

s/Do you still want to upload this module?/Upload rejected./

On Tue, Jun 04, 2002 at 10:26:22AM -0700, Larry Wall wrote:

> : 3. Module removal should be as easy as installation.
> 
> Fine.  There ought to be something in the metadata that says, "This version
> of this module hasn't been used since 2017."  Then you can clear out the
> deadwood easily.  Course, disk space will be a little cheaper by then, so
> maybe we'll just hang onto everything forever.

Nu?  If you mean used in the sense of 'use foo', that would imply all
running programs would have to write some sort of usage db, or touch
a global file, or a lot of other things that I don't think are going to
fly.

> : 1c. Distinctions like "alpha", "beta", and "stable" need to be made
> : according to some convention (a la 

Re: 6PAN (was: Half measures all round)

2002-06-04 Thread Austin Hastings


--- 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 the
> default)
> : "Use the latest version of module Foo"
> : "Use the latest stable version of module Foo 1.xx"
> : "Use the latest version of module Foo 1.xx"
> : "Use module Foo 1.2"
> 
> Yes, there have to be ways of getting at modules by their long names,
> their
> short names, and various intermediate wildcard names.  Perl 6 will
> have to
> keep track of which version you used, so when you use the short name,
> it
> knows which long name you really mean.
> 

> : 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.
> 

Been done before:

3.1.3. Examples
The following examples of font names are derived from the screen fonts
shipped with the X Consortium distribution.

Charter 12 pt  ...
-Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-IO8859-1 
Charter Bold 12 pt ...
-Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1 
Charter Bold Italic 12 pt  ...
-Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1 
Charter Italic 12 pt   ...
-Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1 
Courier 8 pt   ...
-Adobe-Courier-Medium-R-Normal--8-80-75-75-M-50-ISO8859-1
Courier 10 pt  ...
-Adobe-Courier-Medium-R-Normal--10-100-75-75-M-60-ISO8859-1
Courier 12 pt  ...
-Adobe-Courier-Medium-R-Normal--12-120-75-75-M-70-ISO8859-1
Courier 24 pt  ...
-Adobe-Courier-Medium-R-Normal--24-240-75-75-M-150-ISO8859-1 
Courier Bold 10 pt ...
-Adobe-Courier-Bold-R-Normal--10-100-75-75-M-60-ISO8859-1 
Courier Bold Oblique 10 pt ...
-Adobe-Courier-Bold-O-Normal--10-100-75-75-M-60-ISO8859-1 

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com



Re: 6PAN (was: Half measures all round)

2002-06-04 Thread John Siracusa

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 okay, and just needs some tweaks to work with Perl
> : 6 code?  I really hope that's not the case! :)
> 
> I haven't gotten to that Apocalypse yet.  :-)

Is this where I get scared by the reference to the year "2017" later in your
message? ;)

> : 2. Module packaging, expansion, and installation only requires a working
> : install of Perl 6 (unless the module contains non-Perl code, such as C,
> : etc., in which case the appropriate tools for C builds need to be present:
> : cc/gcc, ld, make, and so on).  Requiring "make" and friends to install pure
> : perl files is a legacy relic, IMO.
> 
> Certainly, though it's trivially easy to come up with something that's even
> uglier than make.  Been done many times...

I'm not really concerned about the syntax so much as the dependency on
"something other than Perl" for simple modules.

Along similar lines, platform-specific binary distributions should probably
be an (automatically-generated during submission?) first class citizen in
6PAN for systems that don't have "anything but Perl" on them (no compiler,
no make, no nothing) but still want to be able to install any 6PAN module...
or, heck, for people who just don't want to be bothered with compiling.

I guess there are OS/library version issues there, but I think you could hit
90% of the "common" target environments pretty easily, and it should be
extensible to cover more exotic targets down the road (which is why it
should be an automatic part of 6PAN and not manual :)

> : 3. Module removal should be as easy as installation.
> 
> Fine.  There ought to be something in the metadata that says, "This version
> of this module hasn't been used since 2017."  Then you can clear out the
> deadwood easily.  Course, disk space will be a little cheaper by then, so
> maybe we'll just hang onto everything forever.

Obviously you meant to type "holographic cube" ;)
 
> : 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.

Well, to have use/require/etc. Support the "get me the latest-stable
installed version" semantics as the default meaning, won't we need some
standard way to define "stable" right off the bat?  Or does "right off the
bat" == "when we get to it"?  Or does the absence of any $STATUS-like
variable imply "stable"?  (That last one seems Wall-ish, if not Perlish ;)

-John




Re: 6PAN (was: Half measures all round)

2002-06-04 Thread David Wheeler

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
> SourceForge, I say! :)  It's not like we're demanding EJB-like API rigidity.
> So we'll continue to have $foo.setBlah() and $foo.blah() and $foo.Set_Bar()
> in 6PAN, for better or for worse.  All I'm asking for is some small meaning
> behind version numbering.  Is that so wrong? :)

Okay, I'll buy that. And I think that suggested guidelines for compatibility
between version numbers would be valuable, but I wouldn't think that we
should enforce it. There may be good reasons to break backward compatibility
in some cases.

> Heh, I was going to suggest that new minor-version 6PAN submissions
> automatically have all the earlier minor-version test suites run against
> them before allowing them to go into the archive... :)

Hmmm...perhaps as a warning:

  All regression tests not passed. Do you still want to upload this module?

That'll stop the vast majority of offenders, and those who upload anyway
will be more likely to have documented changes.

David

-- 
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]





Re: 6PAN (was: Half measures all round)

2002-06-04 Thread Larry Wall

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 very quickly
: > (e.g., the DBI), and a lot of the cruft will be left to die (at least from
: > the Perl 6 perspective).
: 
: 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 okay, and just needs some tweaks to work with Perl
: 6 code?  I really hope that's not the case! :)

I haven't gotten to that Apocalypse yet.  :-)

: In the spirit of Simon's desire to see "radical changes" when appropriate, I
: propose the following high-level goals for 6PAN (yes, that's my favorite of
: the bunch ;)
: 
: 1. Multiple versions of the same module may be installed on a single system
: with no possibility of conflicts.  That means no conflicts of any kind,
: whether it be in Perl code, XS-ish stuff, private shared libs, etc.

Yes, I'm already on record that multiple installed versions will
coexist peacably, certainly on disk, and to the extent that they can
in memory.  We can't stop two versions of a module from fighting over a
shared resource, for instance.  Two different database modules may have
to figure out who really has the connection to the database engine,
and who just thinks they have the connection.  Possibly it would help
to have package variables that are explicitly shared among different
versions of the same package when they represent a shared object.

: 2. Module packaging, expansion, and installation only requires a working
: install of Perl 6 (unless the module contains non-Perl code, such as C,
: etc., in which case the appropriate tools for C builds need to be present:
: cc/gcc, ld, make, and so on).  Requiring "make" and friends to install pure
: perl files is a legacy relic, IMO.

Certainly, though it's trivially easy to come up with something that's even
uglier than make.  Been done many times...

: 3. Module removal should be as easy as installation.

Fine.  There ought to be something in the metadata that says, "This version
of this module hasn't been used since 2017."  Then you can clear out the
deadwood easily.  Course, disk space will be a little cheaper by then, so
maybe we'll just hang onto everything forever.

: I can think of many other worthy high-level goals, but these are the most
: important, IMO.  And number one is by far the most important to me.  A few
: natural extensions of it are:
: 
: 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 the default)
: "Use the latest version of module Foo"
: "Use the latest stable version of module Foo 1.xx"
: "Use the latest version of module Foo 1.xx"
: "Use module Foo 1.2"

Yes, there have to be ways of getting at modules by their long names, their
short names, and various intermediate wildcard names.  Perl 6 will have to
keep track of which version you used, so when you use the short name, it
knows which long name you really mean.

: 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. going from 1.xx to 2.xx), and upgrades from one minor
: version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e.
: "backward-compatible").

Fine.  We can separate out interface from implementation better in
the language too.

: 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.

: I don't think the implementation details are too hard to hash out (he says,
: optimistically... ;)  But to meet these goals, they have to be thought about
: early on.  Some of them even require hooks in the language proper (e.g.
: "use/require" extensions.)

Those are details, the like of which would be easy to determine at the last
moment.  But the underlying mechanisms have to be design in, yes.

: Thoughts?  Or has this stuff already been hashed out elsewhere and I missed
: it? :)

It's here and there.  Some of it has been in my speeches, and some in the
Apocalypses.

Larry




Re: 6PAN (was: Half measures all round)

2002-06-04 Thread John Siracusa

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 incrementing the
>> "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor
>> version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e.
>> "backward-compatible").
> 
> This might be asking too much -- it's not very perlish, in the sense of
> TIMTOWTDI. It might make sense for DKs, but different people may want to use
> the conventions their comfortable with. Perl is there for you to create
> applications (and APIs) the way you want, not the way the gods demand.

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
SourceForge, I say! :)  It's not like we're demanding EJB-like API rigidity.
So we'll continue to have $foo.setBlah() and $foo.blah() and $foo.Set_Bar()
in 6PAN, for better or for worse.  All I'm asking for is some small meaning
behind version numbering.  Is that so wrong? :)

>> Thoughts?  Or has this stuff already been hashed out elsewhere and I missed
>> it? :)
> 
> One thing I think is as important -- or perhaps more important -- is to
> enforce the presence of unit tests. There are a lot of modules on the CPAN
> that have no tests, and most of them suffer for it.

Heh, I was going to suggest that new minor-version 6PAN submissions
automatically have all the earlier minor-version test suites run against
them before allowing them to go into the archive... :)

-John




Re: Re: 6PAN (was: Half measures all round)

2002-06-04 Thread John Siracusa

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 think this is a bitch now,
> just wait until simultaneous per-author and per-version installation
> and invocation is allowed as Larry has promised.

Oh, so then this has been talked about before (surprise :)

> I have this horrible fear of perl module installations becoming a bowl of
> spagetti that's been run thru a blender and mixed with a packet of jello.
> Speaking as a 20+-year sysadmin, if CPAN is used for Perl6 with those new
> features and without a massive clean, I foresee a nightmare.

I'm a big fan of the "framework" abstraction as seen I Mac OS X.  All the
big, ugly mess is neatly encapsulated in "atomic" directory structures whose
internals are accessed only through a well-defined (and always backwards-
compatible) API.  The internal organization of these directories can change
over time, and many versions of the format may coexist, since the
manipulation API would understand them all.

Moving modules around should be as simple as moving directories around.
Similarly, removing (all versions of) a module should be as simple as "rm
-rf dirname"

Obviously I favor encapsulation-by-module, where each "module
directory/framework/whatever" contains all installed versions of that
module.  I think that's a better (physical) arrangement than by-author,
by-version, or by-origin.  (Those distinctions can be made in the abstract
through introspection.)

The current Perl 5 module system of physically dividing up files by type and
origin is ins?ane, IMO.  We've got a single Perl 5 "module" installing files
in 10 different, widely-separated directories.  That's a very inconvenient
physical layout, future fancy keep-track-of-what-I-installed-where RPM-like
facilities or no.

Arbitrary (physical) divisions are easy enough once the modules are
individually encapsulated.  I dream of seeing a Perl 6 @INC path (or
equivalent) like:

/usr/local/lib/perl6/core
/usr/local/lib/perl6/site

and that's it!  One directory per "place to look for modules."

-John




Re: 6PAN (was: Half measures all round)

2002-06-04 Thread David Wheeler

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. going from 1.xx to 2.xx), and upgrades from one minor
> version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e.
> "backward-compatible").

This might be asking too much -- it's not very perlish, in the sense of
TIMTOWTDI. It might make sense for DKs, but different people may want to use
the conventions their comfortable with. Perl is there for you to create
applications (and APIs) the way you want, not the way the gods demand.

> Thoughts?  Or has this stuff already been hashed out elsewhere and I missed
> it? :)

One thing I think is as important -- or perhaps more important -- is to
enforce the presence of unit tests. There are a lot of modules on the CPAN
that have no tests, and most of them suffer for it.

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.

Regard,

David

-- 
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]





Re: 6PAN (was: Half measures all round)

2002-06-04 Thread John Siracusa

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 cruft will be left to die (at least from
> the Perl 6 perspective).

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 okay, and just needs some tweaks to work with Perl
6 code?  I really hope that's not the case! :)

In the spirit of Simon's desire to see "radical changes" when appropriate, I
propose the following high-level goals for 6PAN (yes, that's my favorite of
the bunch ;)

1. Multiple versions of the same module may be installed on a single system
with no possibility of conflicts.  That means no conflicts of any kind,
whether it be in Perl code, XS-ish stuff, private shared libs, etc.

2. Module packaging, expansion, and installation only requires a working
install of Perl 6 (unless the module contains non-Perl code, such as C,
etc., in which case the appropriate tools for C builds need to be present:
cc/gcc, ld, make, and so on).  Requiring "make" and friends to install pure
perl files is a legacy relic, IMO.

3. Module removal should be as easy as installation.

I can think of many other worthy high-level goals, but these are the most
important, IMO.  And number one is by far the most important to me.  A few
natural extensions of it are:

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 the default)
"Use the latest version of module Foo"
"Use the latest stable version of module Foo 1.xx"
"Use the latest version of module Foo 1.xx"
"Use module Foo 1.2"

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. going from 1.xx to 2.xx), and upgrades from one minor
version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e.
"backward-compatible").

1c. Distinctions like "alpha", "beta", and "stable" need to be made
according to some convention (a la $VERSION...perhaps $STATUS?)

I don't think the implementation details are too hard to hash out (he says,
optimistically... ;)  But to meet these goals, they have to be thought about
early on.  Some of them even require hooks in the language proper (e.g.
"use/require" extensions.)

Thoughts?  Or has this stuff already been hashed out elsewhere and I missed
it? :)

-John