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