On 17 Aug 2018, at 2:44, Sean P. DeNigris wrote:

> Is there a way to use git in Squeak? If so, does anyone have real 
> experience
> doing so? Pharo and its libraries seem to be moving to git "for real" 
> and I
> wonder about the implications for cross-platform compatibility…

Hello Sean,

did you see my prior messages to you?

Writing from my memory details are a bit sketchy, the code for this was 
written 8 years ago.

I had a fair amount of experience trying to get a squeak images setup 
for particular projects. On several projects we had used Installer DSL 
scripts with some success. We had initially thought that Installer was a 
way forward for cross-fork development; at least you could load stuff.

The drawback being that Installer was too hacky a solution for Pharo 
purists, who went in their own 10 different directions, and developed 
another 10 different tools. This was probably nice for pharo users, but 
not helpful for cross-fork development enthusiasts. As a developer of 
modules that I desired to load into all forks (squeak/cuis/pharo/cobalt 
etc), I could not see how pharo-only tools at this basic level was 
helpful to the cause.

Eventually I decided to start afresh with a plan for converging the 
forks, making my initial experiments with cuis. The new strategy aimed 
to get as much bang, for as little effort as possible. The result was 
something like this:

Strategy A - Image Preparation from Packages
============================================
1. Assume and expect a starting image with ZERO tools, and have ZERO 
dependencies on tools such as PackageInfo, Monticello, 
MonticelloConfigurations, Installer, Metacello or Gofer. Thus any 
solutions developed would work in all forks.

2. Assume and expect no dependencies on online resources, repositories, 
squeak map, universes, squeak source etc.

3. Don’t try and be too clever, avoid solutions that do automatic 
dependencies.

4. Keep things as simple as possible, but theoretically capable of 
setting up an image into any desirable state

5. No GUI.

Strategy B - Image State Export
===============================

1. Be package loader agnostic. The coder can load any package via any 
means to get their image into the working state desired.

2. Provide Package/ChangeSet export facilities to export some/all 
packages from any image into a format that Strategy A tools can use as 
an input.

3. again no GUI

Other Policies
==============
1. Aim to support unloading of things as effectively as loading.

2. Build any advanced packaging tools which use dependencies etc. 
without dependency on any other tools (if possible).

3. Anything advanced that is used for loading or setup can therefore 
also be unloaded prior to Export (B).

4. No GUI

So… The result…

Strategy A
==========

Implemented a single simple class, InstallSeries

InstallSeries loads .st files in a defined order. You provide a list of 
directories for InstallSeries to load from. Each directory is likely a 
repository clone. Hence the link to your git-hub question.

Given the list of desired projects to load, InstallSeries loads all of 
projects in a series of steps.
The level-1 resources from all projects are loaded first.
The level-2 resources from all projects are loaded second.
The level-3 resources from all projects are loaded third.
..
The level-N resources from all projects are loaded N-th.

If I recall:

level 1 was for bug-fixes and patches to the base image.
level 2 was for patches to the base image that provide api-parity across 
images
level 3 was for lower-level frameworks
level 4 for higher-level frameworks
etc.
etc.

A project like Grease would be loaded in level 2
A project like Magma, would be loaded in levels 3-4
A project like Seaside, would be loaded in level 4
A project like Seaside-Magma, would be loaded in at level 5
A project like Pier, would be loaded in level 6

In other words, a very-poor-mans dependency mechanism. But also, if the 
usage of a package (e.g. Seaside) requires specific bug-fixes to be 
applied in a specific destination image. This bug-fix can be packaged 
into the Seaside repository in the appropriate position in the 
hierarchy, and the knowledge of what is needed for what to work where 
can be captured.

Strategy B
==========
A simple Exporter class knows how to export ChangeSets.
Alternative Exporter classes can export in other formats.

A Package is defined by a packaging-method, that makes calls on the 
chosen Exporter to create the exported file. The result is slightly less 
dumb that an existing ChangeSet. It can specify a dependency on the 
existence of a specific Superclass, or instance variable and add it if 
it is not present. Such cleverness can make dependencies far less of an 
issue and handle all of the monticello use cases without PackageInfo or 
Monticello.

Pragma definitions within the packaging-method determine the default 
filename/level for the export.
A ChangeSet (or slice) is similarly defined making calls on the 
Exporter.

A category of packaging methods, can be loaded to provide specific 
package exports
Defaults can export all-packages.

In conclusion, most of this was working in an alpha state. The code is 
available on launchpad under the smalltalkers group. I am aiming to dust 
it off and get it all up and running at some point.

best regards

Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180817/a9a99b45/attachment.html>