On Fri, Dec 11, 2009 at 11:14 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
> Folks -
>
> Here is the long overdue post about packages and how to manage them. One of
> the things that comes directly out of Edgars and my desire to unload a few
> more packages, is the question of what to do with them. That raises the
> question of how to deal with external packages in general. So here we go
> with some thoughts on both.
>
> We have various package management systems that all fall short in some
> respect. First, there is Monticello, our source code management system.
> Monticello works reasonably well for maintaining individual source packages
> but is awfully lacking in two core areas: Managing dependencies and being
> findable. MCs "builtin" dependency mechanism is just awful; configurations
> work somewhat better but neither address "higher level" dependencies such as
> "this package depends on Seaside 2.8" (the only way to express this is by
> listing all of Seaside's packages explicitly). Secondly, MC is generally not
> indexable by Google which is a fatal flaw from my point of view (because how
> the hell are you going to find a package if you can't google for it?)
>
> Our second candidate is Squeakmap. Of all the solutions, Squeakmap is
> currently the only one that is indexable by Google; a major advantage.
> However, Squeakmap doesn't have dependencies, rendering it difficult to use
> for non-experts. Squeakmap also has the disadvantage that it's pretty dated
> by now and has been in need of a serious face lift since its inception :-)
> (that said I do like it and would rather like to see it revived)
>
> The third candidate I'm aware of is Universes. Universes is the only
> candidate here which has dependencies that actually work reasonably well. In
> addition, universes can be used off-line so it would be feasible to ship a
> "standard library" with Squeak for people to download and install (a little
> bit like Python's site-packages). The downside of Universes is that they're
> not indexable and their user interface is by far the most awful and unusable
> of all the proposals.
>
> I think that's all the serious contenders at this point (if I'm missing
> something please let me know).



Maybe more attention to the real uses of the technology
outside the "core" squeak is needed here.
Since some months ago, Dale Henrichs has made available Metacello
that doesn't tries to "fix" monticello, but to build on top of the
limitations of it
by treating monticello as what does better: to load a single version of a given
package in the image. Then it adds the apropriate "package" dependencies in
a higher level. No need to feature creep monticello but use it as a sound base
for solving the issues you mentioned.

>From my perspective, I don't care which
> solution we choose as long as it fits the bill of:
> * Being indexable by Google
> * Reasonable dependency management
> * Having a usable UI

I think that you are mixing responsibilities here. The same way that
Git in the FOSS
world doesn't need to be "google indexed" to be useful, the tool
needed by squeak
doesn't need to have all of these capabilities. Different tools can
fulfill the requeriments
you mention.

You can have
- monticello to manage package source code and conflict managment.
- metacello to manage package dependencies
- "some tool" to serve as a web hub (a la github) to store the
metainformation for metacello
to work.

> Since none of the solutions above currently fits all the requirements we'll
> have to fix some. That could mean adding dependencies to SqueakMap; it could
> mean giving Universes a reasonable UI; it could mean fixing dependencies in
> Monticello. I really don't care either way but I think we'll have to figure
> something out here. Is anyone out there interested in or perhaps even
> working on addressing any of these issues?

Please, let behind that "squeak for all" mentality. The right tool for
the right job.
One tool (squeak or any other) can't solve all the problems.

And respect to squeak map/universes and "species" please, please, they are
in this almost 2010, plain prehistoric. Don't let them live out of
their time (they were
useful I am sure, ten year ago) by adding more features to some old codebase.
Seaside is a marvelous tool, and can be used to build something more "user
attractive" (again, a la github).

>
> The second big issue is how we deal with "core" vs. "extended" packages in
> Squeak. As we move towards a smaller kernel, we should know which packages
> are core and which ones are not. And when we remove packages that are
> currently part of the image, we need a place to put them.

Discussend long time ago in Pharo. Some useful ideas can be gathered
from there,
even if the project name produce some bad feelings.

>
> In addition, we really need to start thinking about the packages that a
> "standard" Squeak should contain. Personally, I feel that one of the best
> decisions David and I made in Croquet was having the small base image be
> tucked away in the distribution so that people who want to build something
> small have a starting point but with the "standard" build being a fully
> featured set of packages that contained everything we wanted to show.

Same here.

>
> I think the approach is perfectly applicable to Squeak - we need to move the
> "core" image aggressively forward; every release should make it
> significantly smaller. And while we're doing this we should have a
> "standard" image (not necessarily a kitchen-sink image with *everything*
> thrown in) but the packages that we think your average Squeak user would be
> interested in seeing.

Same here.

>
> If people agree with the direction of aggressively shrinking the core image
> as well as figuring out what the default image should contain then our next
> steps should be:
> * Figure out where to place unloaded packages (we could leave those in trunk
> if we wanted to but I'm not certain that's the right place; perhaps Edgar's
> Ladrillos could work?)
> * Figure out a build process that we can apply to the core image to build
> the default image automatically
> * Discuss and decide which packages should be part of the standard Squeak
> version
> * Unload some more packages!

I will risk my own permanence in the squeak mailing list because I
could be banned
by being labeled as troll or pharo gruppie. This is an honest
question. Why don't you
consider or at least follow the pharo discussion, as I see it now,
Squeak is walking
the same path pharo has already left behind. Same discussions about future,
about core vs  full distributions, about external packages, about
package management,
heck even about the today discussion about the image update number!

So the question is, has ever been considered to simply build the bridge between
communities and to use the PharoCore image as the base for Squeak?

I want to express my respect for the work made in Squeak (but also the work made
in Pharo) and overall the work of the people integrating changes from
one project
in the other no matter where the change originated. This is amazing.

But I am more than disappointed to see this discussion taking place
here as if the
world were only Squeak and the knowledge of the outside events and ideas weren't
worth even the time to having a look in them.
I am active in pharo, but always read the squeak list because I want
to be informed
with the activities, goals, technology and overall, people involved.
This by itself is
very valuable to me.

>
> So far my thoughts on the issue. Feedback is very welcome, I think we need
> to move forward on this set of issues before the next release goes out.

What release. This means that the 3.11 (that millions of times were
stated as being
only about the process and not about a new squeak release) is over and squeak
is heading to the next (4.0) release?

This doesn't align with the stated goals for squeak. Has the board a
new roadmap for
squeak?

>
> Cheers,
>  - Andreas
>

Very respectful and wanting to avoid a flame war,
--
Miguel Cobá
http://miguel.leugim.com.mx