[squeak-dev] Re: Packages, Packages, Packages

Miguel Cobá miguel.coba at gmail.com
Sat Dec 12 15:52:27 UTC 2009

On Sat, Dec 12, 2009 at 1:43 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
> Miguel Cobá wrote:
>> 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.
> I do not understand which problem domain Metacello is addressing and how. If
> you have more information, this would be very welcome.



Quoting from the blog post:

Metacello: Package Management for Monticello

August 25, 2009 in Deployment, Metacello, porting

Rate This



Metacello is a package management system for Monticello. A package
management system is…

…a collection of tools to automate the process of installing,
upgrading, configuring, and removing software packages from a
computer. Distributions of Linux and other Unix-like systems typically
consist of hundreds or even thousands of distinct software packages;
in the former case a package management system is nice, in the latter
case it is essential.

Packages are distributions of software and metadata such as the
software’s full name, description of its purpose, version number,
vendor, checksum, and a list of dependencies necessary for the
software to run properly. Upon installation, metadata is stored in a
local package database.

A package management system provides a consistent method of installing software…

Last April I finally became fed up with the lack of a decent package
management system for Monticello and decided to write my own from
scratch. I wanted a package management system for Monticello that was
consistent with the important features of Monticello:

    * Declarative modeling. A Metacello project has named versions
consisting of lists of explicit Monticello package versions.
Dependencies are explicitly expressed in terms of named versions of
required projects. A required project is a reference to another
Metacello project.
    * Distributed repositories. Metacello project metadata is
represented as instance methods in a class therefore the Metacello
project metadata is stored in a Monticello package. As a result, it is
easy for distributed groups of developers to collaborate on ad hoc
    * Optimistic development. With Monticello-based packages,
concurrent updates to the project metadata can be easily managed.
Parallel versions of the metadata can be merged just like parallel
versions of the code base itself.

Additionally, the following three points are important considerations
for Metacello:

    * Cross platform operation. Metacello must run on all platforms
that support Monticello: currently Squeak, Pharo and GLASS.
    * Conditional Monticello package loading. For projects that are
expected to run on multiple platforms, it is essential that
platform-specific Monticello packages can be conditionally loaded. At
the moment, conditional loading is specified based upon the following
          o #common. Code that is common across all platforms.
          o #squeakCommon. Code that is common to Squeak and Pharo.
          o #squeak. Code that is specific to Squeak.
          o #pharo. Code that is specific to Pharo.
          o #gemstone. Code that is specific to GemStone.

      It should be possible to inject project-specific attributes, so
code that is dependent upon attributes not covered by the standard
list can be conditionally loaded. For example, in GLASS, different
Monticello package versions are loaded based on which version of
GemStone/S is running (i.e., version 2.0 versus 3.0).
    * Compatible with MC2. It must be possible to manage Metacello
projects that are based on alternate Distributed Source Code
Management systems like Monticello2.
    * MIT license."

>>> 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.
> I'm not claiming it can. I'm laying out a couple of issues that we need to
> address, and list the current options as far as I  understand them. The only
> thing I'm strongly against is to end up with another dependency on a tool
> that hasn't been written yet and that by the end of the day will the job
> just as incomplete as the alternatives.

I think that is not "another tool" but it is created from a vendor (Gemstone)
 to address a real problem.
So, it will get more attention than a altruist-generated tool (because of
costumer pressure). This is good for all.
Also, in GLASS, Metacello is used for loading the next version 3 of Seaside
and all of dependencies.
Also, Mariano Martínez Peck et al have started to create
configurations for all the
packages that are part of the dev distribution of PharoCore.
This will allow an apt-get behavior in installing packages.

>>> 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.
> Can you summarize the results of that discussion?

Well, core will always tend to be smaller, right now, PharoCore 1.0 rc1 is 11 MB
in size. All the other packages are being extracted to own
squeaksource repositories.

Also, a list of packages to be included in PharoCore and a list of
packages to be
included in dev and web distributions are available in the wiki part
of the Pharo

>> 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?
> This wouldn't work for the same reasons that it wouldn't work to use a
> Squeak-trunk image as the basis for Pharo. You should propose that at some
> point just to see what kind of reaction you get ;-)

Well, but it is only now that squeak has reached the point where it
could be considered
a core part of other distributions. Pharo has advantage here. It has
several months
being a small core image that could be used as the infrastructure for
other forks, as
sometimes ago was proposed in the squeak list.
So, yes, maybe squeak trunk is approaching to a core image with everything added
as external packages, but it remains some steps more to be there: packages
tested as working, release policy, release process, documentation for new users
and what to expect when updating, how to use the core squeak, a new
updated page,
update documentation, tutorials, a book, promotion, blogs, articles,
the resolution about
the license, etc.

> Cheers,
>  - Andreas

Miguel Cobá

More information about the Squeak-dev mailing list