> Can we discuss something like the CPAN for Squeak?

I like the idea. From a practical point of view it seems that relaxing 
the rules at SqueakMap such that "registered" access becomes an option 
seems the most realistic approach. In addition, one might consider 
creating a breed of SM and Squeaksource by having SM automatically index 
SqueakSource projects.

Cheers,
   - Andreas

Randal L. Schwartz wrote:
> Since I promised the folks in #squeak I would start this thread...
> 
> It's been my observation for quite a while that Squeak is missing
> the equivalent of what Perl has in the CPAN.
> 
> First, let me describe the CPAN:
> 
> Anyone can get a CPAN ID for free.  Once they have a CPAN ID, they upload
> packages to a central server, which are then indexed and replicated to 500+
> places worldwide, usually within an hour.
> 
> A package has a name and a version number.  Version numbers are floating point
> numbers, with "larger = better".  If the version number contains an
> underscore, it's considered "better, but only beta" and not automatically
> offered as an upgrade (see below).
> 
> In general, package names are *not* registered, meaning that if I upload
> Foo-3.4, and you upload Foo-3.5, users around the world will be asked if they
> want to upgrade my package with yours.  By default, this allows cooperating
> team members to upgrade new releases of a cooperative project, as long as they
> work together on the version numbers.  This also allows the
> long-gone-developer's code to be updated in-absentia.  Although this has the
> possibility for abuse, in the 15 years of the CPAN it has only been abused a
> few times, and the CPAN gods can quickly remedy the situation.
> 
> For more managed care, a package name or prefix can be *registered*, which
> means only a small group of individuals can upload things in that prefix.
> Again, this is rare, but solves the wildcard issue.  If a package is
> abandoned, the CPAN gods can transfer the registration or deregister it.
> 
> Any CPAN package can declare that it is dependent on another CPAN package, or
> even particular versions of core-installed packages.  The CPAN installer can
> be told to automatically or manually install all dependencies (or even ignore
> them, but that's rarely wise).
> 
> Speaking of which, the core Perl distro has had a CPAN installer for many
> years (CPAN.pm), and even a newer one (CPANPLUS.pm) has been included in
> recent releases.  As long as the CPAN index can be read, and the packages
> downloaded, anyone can write additional CPAN installers too, but they probably
> won't go into the core.
> 
> As a result of the above rules:
> 
> * CPAN installation is easy
> * CPAN publishing is easy
> * The CPAN is vital and thriving - see search.cpan.org/recent
> 
> Notice about 50 uploads a *day*.  And everything *works* in an
> automated way, except for the "CPAN gods" exceptions listed above.
> 
> Now.  Squeak has been around only half as long as Perl.  But that's about
> how long Perl was around before we came up with the CPAN, so it's about
> time Squeak had the same thing, I think.
> 
> Here's what I know (and I could be wrong):
> 
> Squeakmap - *everything* is "registered", so cooperation is hard
> Squeaksource - no index is made, so you have to find things yourself
> Universes - like Squeakmap
> Sake/Packages - single point of update, making publishing hard
> 
> And except for Squeakmap, there's none of these that have been in all of the
> recent Squeak releases for installation, so we have a bootstrapping problem.
> Even installing Universes is hard from Squeakmap. :)
> 
> And all of these systems are missing dependency and automatic upgrade
> management.
> 
> Can we discuss something like the CPAN for Squeak?
>