[squeak-dev] SqueakMap is a "Showroom"

Here are the package requirements I've been hearing in these threads
and are congruent with my own:

1)  Easy-installation.  One-click installation of multi-package
software systems, including, if necessary, execution of install
scripts and local deployment of resource files.
2)  Easy-publication.  One-click deployment of multi-package software
systems, including install scripts and resources).
3)  A full SCM collaboration system, with diffing, merging and
distribution across multiple repositories.
4)  Ability to plug into any other existing or future packaging system.

Requirement #3 is met by Monticello.  Requirements 1, 2, and 4, used
in the context of an appropriate lifecycle, can be met solely with the
existing Monticello and SqueakMap tools we have today.  And there are
just two steps to get there, one of which is just a change of
*thinking*!

  step 1) Assimilate this thought:  "Anyone integrating multiple
programs (packages) into a single image is doing development."
  step 2)  Humans make all SqueakMap packages one-click loadable and
only publish one-click-loadable packages going forward on SqueakMap.
Do this via the SAR install script, making calls to other packaging
systems as necessary (satisfying requirement #4).

By doing just these two things we don't need any other tools and
SqueakMap doesn't need dependencies to meet the four requirements.  At
the same time, other tools can be used and called from the SAR script
if desired.

SqueakMap is the "Squeak showroom" place for exploring what packages
are about.  We only expect SqueakMap to load a *single* package into
the image which it says is compatible.  Of course, we know we can load
more than one, but the included Test Suites provide my comfort on
whether everything still "works".

We don't worry about conflicts between package versions loaded from
SqueakMap because that requires deliberate package integration in
which you use Monticello, not SqueakMap.  The maintainer will update
his dependency list soon enough if we make publishing to SqueakMap
easy.  I added a "BuildSar" button to Monticello Configurations
browser so I could at least build the SAR in one-click, which I then
have to manually upload to SqueakMap.

 - Chris

Put another way, if we use SqueakMap solely as a tool for consumption
of software, and Monticello for production (and consumption) of
software, improve the bridge between the two (publishing) and we're
basically Done..!  Seriously, what else is missing?

Chris Muller wrote:
> Put another way, if we use SqueakMap solely as a tool for consumption
> of software, and Monticello for production (and consumption) of
> software, improve the bridge between the two (publishing) and we're
> basically Done..!  Seriously, what else is missing?

I agree, this can be a easily achievable base for evolving further.

I have quite some time in mind to start with a first step: a SqueakMap
web "uplift", that is, a reimplementation of map.squeak.org to be more
user friendly but also more fresh looking and modern.

We can then make the next step in that evolution: adding a good
dependency support, with merging Universes approach or somehow
different. If we merge that part of Universes which seems to work really
well, we did a first unification: between SM and Universes. End user
will now be happy, installation will be as simple as possible: one click.

Next step is better and as user friendly as possible integration with
Monticello as in-image tool for package and version control. This would
be preferable for publishers.

Another step would be adding/merging Sake/Packages and LPF, at least as
I understand Keith's work.

Evolution and unification of existing tools, that's my proposal, not
revolution and doing everything from scratch again and again. Well, for
experimental purposes revolutionary approaches are welcome, but as we
can see, those projects loose breath somewhere in the middle. But we can
incorporate ideas from that experiments in our evolutionary tools.
That's how I see things.

Janko


--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

On Fri, Jun 27, 2008 at 11:39 PM, Chris Muller <[hidden email]> wrote:
> We don't worry about conflicts between package versions loaded from
> SqueakMap because that requires deliberate package integration in
> which you use Monticello, not SqueakMap.  The maintainer will update
> his dependency list soon enough if we make publishing to SqueakMap
> easy.  I added a "BuildSar" button to Monticello Configurations
> browser so I could at least build the SAR in one-click, which I then
> have to manually upload to SqueakMap.

I'm not sure I understand, is this deliberately ignoring all
integration problems ?

What if you need two packages from separate developers, they have to
agree on what they include on each side ?


--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

> I'm not sure I understand, is this deliberately ignoring all
> integration problems ?

No, I am saying use Monticello for handling integration problems.  If
you load one multipackage software system (MPSS) from SqueakMap and
another different MPSS has a earlier version of one of the same
prerequisites, you open up a Monticello browser, load the specific one
you want, run the test cases, etc.

If these two MPSS's really have a purpose together in the same image
then you are developing yet a new MPSS based on these other two.
Monticello is the appropriate tool for assisting with that integration
(not SqueakMap).

Once you've got them together you can easily post your own *new* MPSS
to SqueakMap which combines the function of the other two.

> What if you need two packages from separate developers, they have to
> agree on what they include on each side ?

Not at all.  You cherry-pick what YOU need from each for your stuff.



On Sat, Jun 28, 2008 at 8:16 AM, Damien Pollet <[hidden email]> wrote:

On Sat, Jun 28, 2008 at 5:42 PM, Chris Muller <[hidden email]> wrote:
So basically, either users duplicate the integration work for
combinations of packages not prepared before, or they publish their
combination for others to reuse, resulting in as many new specialized
combination packages ?

First, this kinda defeats the purpose of a package system to me, and
second, what difference does that make w.r.t MC configurations?

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

>> ...
>> Once you've got them together you can easily post your own *new* MPSS
>> to SqueakMap which combines the function of the other two.
>
> So basically, either users duplicate the integration work for
> combinations of packages not prepared before, ...

If a combination wasn't prepared and published before then, by
definition, that combination hasn't been meaningful enough as a
singularity for anyone to have performed such integration.  Since it
hasn't been done before, there's no duplication of work.

> .. or they publish their
> combination for others to reuse, resulting in as many new specialized
> combination packages ?
>
> First, this kinda defeats the purpose of a package system to me, and

You forgot to do step 1.  Reduce your expectation of SqueakMap from
being a "packaging system".  That's Monticello.  Instead, SqueakMap is
just a showroom from which you expect to be able to *easily* review
and learn about a package.  This is why I encourage SqueakMap packages
to not be shy about pop-ups to introduce the package to the user, even
utilising Squeaks multimedia capabilities in an engaging way if
possible.  Talk about on-line documentation and the attraction that
would be for new users (and me too!).

I really like what OSProcess does when it loads up, showing you the
current VM process and some docuementation.

> second, what difference does that make w.r.t MC configurations?

A one-way bridge from MC to SqueakMap would not be difficult or
time-consuming to build.  MC Configurations has been useful for me in
that bridge because it allows one-click generation of a
self-installing SAR (all packages in order) that I simply upload to
SqueakMap.  Of course, it might be nice to have a one-click including
SqueakMap upload directly from the image...



>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet
>
>

On Sat, Jun 28, 2008 at 7:25 PM, Chris Muller <[hidden email]> wrote:
Maybe. But ideally a package manager doesnt even require the work to
be done. Each package *locally* defines what it needs and what it
provides, and "integrating" is just choosing something else than the
default when there are several possibilities to fulfill a dependancy,
effectively making a new adhoc composition.

> You forgot to do step 1.  Reduce your expectation of SqueakMap from
> being a "packaging system".  That's Monticello.  Instead, SqueakMap is
> just a showroom from which you expect to be able to *easily* review
> and learn about a package.  This is why I encourage SqueakMap packages
> to not be shy about pop-ups to introduce the package to the user, even
> utilising Squeaks multimedia capabilities in an engaging way if
> possible.  Talk about on-line documentation and the attraction that
> would be for new users (and me too!).

Then this is useful only once per user, at the first installation.
IMHO this would be better fulfilled by having nice (read HTML with
links and images) class/package comments in the image and a way to
navigate them like a manual rather than randomly picking classes and
methods. SqueakMap should also present these comments online so you
can see what the package does before installing it.

However, this is orthogonal to the need to say "I need X" and have the
system automatically install all the necessary, while not forcing
people to maintain each and every used combination separately.

Ex. Pier needs Seaside. If there is a new release of Pier, the Pier
developers update the Pier package and nothing more. If Seaside gets
upgraded, the Pier package should *not* have to change/be
regenerated/whatever until the Pier code is updated.

> I really like what OSProcess does when it loads up, showing you the
> current VM process and some docuementation.

Do you like to close the same 12 windows each time you rebuild an
image or upgrade the package ?
What when OSProcess gets installed because it is used behind the
scenes by the actual thing you want ?

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

 
>
> I really like what OSProcess does when it loads up, showing you the
> current VM process and some docuementation.
>
>  
I really hate it... at the end of building a large image you have to go
around closing all of these unwanted windows.

For which I had to write a package - squeaksource.com/Scripter

best regards

Keith