Hi all!

Being the principal developer of SM I thought I should "chip in", note
though that I have NOT read this thread and I am going to Mallorca
tomorrow. :)

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

Mmm, anyone can register on SM. One of the primary ideas with SM was to
not only keep track of packages but also of developers.

SM does have a very simplistic upload facility but it was mostly added for
hosting simple scripts.

And of course, SM lacks signatures etc. And there is no replication of
packages themselves - except for the server keeping a server side cache
(not very well known), but it was on the other hand designed more like a
"freshmeat" than a "cpan" - the map is downloaded and cached locally
inside your image.

This was btw also a primary idea - the fact that the whole map is a true
object model that you can easily use with normal Smalltalk. I still find
that aspect quite nice, even though the monolithic nature is something I
have wanted to move away from for several years.

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

SM keeps track of releases and each release has both an automatic version
number and a manual one. The automatic one is not that good (doesn't
support branching that good actually).

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

SM instead has a concept of co-maintainership - a maintainer can add other
developers as co-maintainers and they can more or less do the same stuff
as the maintainer can.

SM also has the ability to transfer packages. Hmmm, can't recall right now
if that is offered in the UI.

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

If someone wants to co-maintain it is IMHO quite easy to contact the
maintainer and get added as a co-maintainer. If the maintainer does not
answer - you can always talk to the SM "gods" = being me more or less.

But I very seldom get such calls so I am not sure this is a BIG problem
(yet).

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

Again, transfers are easily done in SM too. This is also why it has a
separate Authors-field, in order to give credit to the original authors
despite the current maintainers.

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

There is no dependency management in SM today. I started one model,
another guy did one too (can't recall his name) - and I asked him if he
could just add it and then take responsibility for maintaining it -
because I didn't quite grok the code - but there was no such interest at
the time.

I have repeatedly asked for help in adapting SM and adding dependencies,
but so far only a very few individuals have expressed interest in helping
out. Please, please, please raise your hand! :)

It would be great to:

- Clean the model, make it distributed and also make it "bidirectional" so
that client images can also "upload" model changes and thus open up for
Morphic UIs for maintaining packages (and not just the web UI).
- Smack a new Seaside good lookin UI on top of the model.
- Add dependencies to the model.
- Make it aware of Installer, Universes and Squeaksource
- Add free text indexing. In Gjallar we already have nice code for using
Swish-e.

...and of course there are tons of other things we could do.

[SNIP]
> Here's what I know (and I could be wrong):
>
> Squeakmap - *everything* is "registered", so cooperation is hard

Mmmm, not sure what the above means.

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

Hehe, of course. Ever since I created SM we *have* been discussing it AND
making things happen. When SS came around I expressed fears that it would
"compete" with SM. People didn't really agree - but I think we can clearly
see it today. Universes came about in order to attack lack of dependencies
in SM and I have repeatedly argued for merging Universes/SM but without
really getting any traction for that idea.

These days I don't have THAT much time to share - but IF there were a few
individuals standing up - I would definitely help out making something
happen. It just takes 2 raised arms. Or perhaps even just one. :)

regards, Göran