[Cuis-dev] Siren progress and questions (Packages)

[ken.dickey at whidbey.com]

Packages are used a bit differently in Cuis.

The gist of the idea is that we have named Features, which you don't 
have to load unless you want them.

If you do want something (e.g. `Feature require: #'UI-Tools'.`) then 
that package is cheked to see if it has any requirements which are not 
yet loaded.  Those packages may also have requirements to be successful. 
  The preflight does a transitive closure of all requirements and either 
raises its hand any lets one know that it can't find some requirement 
with the right versioning, or all required packages are loaded and then 
the package that requires them.

So packages are not meant to require specific Classes, but to require 
packaged Features which contain any required code.  Avoid "library 
hell".

Now the package format is pretty close to the old *.pkg format and a 
naming convention is used to gather classes and methods together. (e.g. 
'UI-Tools' classes and methods in '*ui-tools' method category).  But 
that is simple mechanics.

It is assumed that the Cuis-Base contains all the code to run the base 
Cuis IDE and not much else.  This is why the Cuis base image 'Smalltalk 
allClasses size' typically answers somthing in range 500-600, even 
though we are always adding things like syntax hilight, vector graphics, 
Unicode, TrueType font support ..  The last time I looked, the Squeak 
base was over 2700 classes and Pharo over 10,000 classes.

If something does not need to be in the base image, we can package it 
up.  The method is simple, but has been quite helpful so far in allowing 
us to have a reasonably robust composition strategy where we start with 
a released base image and (re)require packages in development.

One way I have made use if this is the problem of saving a live Morph as 
a referenceStream into a file whith a name which I can later require and 
get it back.  The #'Morphic-Packager' UI tools package adds a `save me 
as a Package` menu item to a Morph's menu which files out the Morph and 
creates a package with requirements on all code packages which are 
needed to "run" the Morph in question.  I.e. one gets back not only an 
unpickled Morph object but all the backing code required to use it.

If you browse Cuis-Smalltalk-UI/tools/Morphic-Packager.pck.st you will 
see now simple this was to do.

I believe Cuis is currently unique with this particular composition 
strategy.

So yes, please help us out toward better tools and better explinations.

HTH,
-KenD
==============================================================================================
> On Dec 1, 2022, at 9:47 PM, Luciano Notarfrancesco via Cuis-dev 
> <cuis-dev at lists.cuis.st> wrote:
> 
> Hi Stephen,
> A package can overwrite a method in a system class or in a class from 
> other package it depends on. For example if you package name is 'Siren' 
> you have to put the new method in a message category starting with 
> '*siren', such as '*siren-printing', etc (or '*Siren-printing', case 
> doesn't matter).
> 
> On Fri, 2 Dec 2022 at 10:30 Stephen Travis Pope via Cuis-dev 
> <cuis-dev at lists.cuis.st> wrote:
> 
> Oh, I forgot one other question: Is there a way to merge packages, or 
> are they bound to system class categories?
> 
> Siren has many categories, and the Package tool implies that 
> merge/delete is an option.  It'd be great if one could select multiple 
> packages and merge them.
> 
> I did figure out that I can make one package that has the all other 
> categories in its group as prerequisites.
> 
> How does one add random system class changes to a package?
> 
> Is it possible to make a package with a class that's in a system 
> category (i.e., one with other classes in it that aren't in the 
> package)?
> 
> ...any replies appreciated...
> 
> stp