[squeak-dev] How do I create SqueakMap package for loading an MCConfiguration?

Chris Muller asqueaker at gmail.com
Sat Jan 17 23:27:59 UTC 2015


> I've had quite an odyssey to come to my present understanding of the
> SqueakMap package loader. The way I now understand it is as follows:
>
>  SqueakMap packages can be seen in the middle-left list pane of SqueakMap
> Package Loader. The context menu in this pane filters which packages to
> show. The bottom-left list pane appears to be another selection filter. I
> deselect all to avoid surprises.

Yea that sounds right.  Honestly I really do not like the hierarchical list
I would prefer a more Smalltalk-like browser approach with packages in left
pane, releases in middle pane, details in bottom pane, etc.

> Details about the selected package are shown in the right pane.
> A selected SqueakMap package can contain releases. Available releases are
> listed below the package name in the  SqueakMap Package Loader.  A new
> release  can be created though the context menu of a selected package:
> "Create new Release". (There are more alternatives that I haven't
> investigated.)
> Details about a selected release are shown in the right pane. One detail
> shown for every release is called "Download: <URL>". The URL identifies a
> file that specifies the installation. I have seen an .st file that will be
> executed as a doIt, and a .sar file that contains 3 .st files: a preamble,
> an installation file, and a postscript.

A .sar file would also contain whatever /resources/ were needed for that
application to run.  Many catalog entries do not need resources, but the
ones that do, can use SAR files as a means of one-click deployment.

Otherwise, a plain .st script can be used to download resources from some
location (along with code packages for a correct configuration).

Normally each correct configuration script is specified for a specific
version of Squeak.

> One command available for a selected release is "Edit release".  This
opens
> a "fill-in-the-form" called a Release browser. Most fields are explained
by
> hovering the mouse above the field. The exception is the bottom field; it
> can contain a script for the installation. I haven't found a good
> explanation for this script anywhere.

Yes it's the .st script which performs the installation.  There is a
detailed description with example here:

  http://wiki.squeak.org/squeak/6182

It explains the two kinds of scripts that should be written for each
SqueakMap catalog entry, 1) the fixed-configuration (for specific Squeak
version) and 2) the head release (latest code).  It explains the rationale
for when you would want just #1, or both #1 + #2.

> I first thought it wasn't important
> because most releases shown in the package loader leave the script empty.


That's only because most packages on SM are from before the time this
ability to "Edit Release" was written in 2012.  At that time, I started
trying to encourage people to use SM as a Catalog and not a SCM tool.  IOW,
use .st scripts only (unless embedded resources are needed, then a SAR).

I personally am not going to store any more .mcz's on SqueakMap.  I only
want my .mcz's in the SCM repository (SqueakSource, SS3, etc.).  The
rationale for this is in those wiki pages linked together.

> I
> now see the field as an input field. Fill it with executable Squeak code
and
> save it. It will then be transformed into file, stored somewhere, and
become
> retrievable through the URL in the "Download: <URL>". This scheme seems
> extremely powerful but only for the person who knows the various
> installation mechanisms.

That's true but all catalog entry's can generally follow the same format of
script, so you can clone pretty easily one and get all the great features
like dependencies for literally just a few lines of code.  The format of
every "fixed-configuration" script is:

    (check if first required dependency is already loaded) ifFalse:
        [ SMSqueakMap default installPackageNamed: 'The Dependent Package'
version: '1.1' ].

    (check if 2nd required dependency is already loaded) ifFalse:
        [ SMSqueakMap default installPackageNamed: 'The Dependent Package'
version: '1.1' ].

    #('My-Core-Package-cmm.123' 'My-Tests-Package-cmm.123') do:
        [ : each | (Installer repository: '
http://ss3.gemstone.com/ss/Ma-Client-Server') install: each ]

The way I check for the presence of required dependencies is simply
(Smalltalk hasClassNamed: #SomeClass) where I know SomeClass only exists in
that other package.  I know this is not ideal but the good news everyone
can do precisely what's ideal for each project.

See an example on SM for an example of a proper "head" script.  It's
basically the same except instead of loading specific package versions it
uses McmUpdater, the same mechanism we use for trunk, so that each SM
project can have community features too.

> Chris pointed me to a script statement for downloading a SqueakSource
> package known by its URL. e.g.,
>        (Installer repository: 'http://www.squeaksource.com/DCI') install:
> 'BBAllInOne-TRee.18' .
> this happens to be an  Monticello configuration file,
> BBAllInOne-TRee.18.mcm.

Installer can install .mcm file fine.

> Another statement I have seen is
>          SMSqueakMap default installPackageNamed: '<name>' version:
> '<version>'
> I couldn't make it work for me, but suspect that the package shall be
stored
> as a versioned file in SqueakMap itself.

That should work as long as '<version>' of '<name>' exists -- it will
simply run that file at Download URL for that package and this is how
pre-reqs are done.

I tested it yesterday and it worked, which one is not working fo ryou?

> This is as far as I've got. I hope somebody will correct the explanation
> where it is wrong so that other people may make use of it.  I would have
> been spared considerable time and frustration if I had seen it a couple of
> weeks ago.

Good that you persevered since you now can easily publish packages that can
use any SCM technology with resources, demos, etc.

Cheers.

> Cheers
> --Trygve
>
>
>
> On 15.01.2015 20:52, Chris Muller wrote:
>
> On Thu, Jan 15, 2015 at 4:02 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
>
> On 14.01.2015, at 21:32, Chris Muller <ma.chris.m at gmail.com> wrote:
>
> Most SqueakMap packages do not have a script; they
> only have a "Download URL".
>
> They /all/ have a Download URL.  What varies is what type of file is
> found at that url.  When you entered the script above and clicked
> "Save" in the Release Editor browser, it saved it as a ".st" file on
> the SM server, with the "Download URL" field pointing to it.
> SqueakMap will still interpret .mcz, .sar, as well as .st files and
> "do the right thing" for each type.
>
> Curious, does it handle .mcm directly nowadays?
>
> It appears not but could be done by adding new subclass of
> SMSimpleInstaller.
>
>
>
>
> --
>
> The essence of object orientation is that
> objects collaborate  to achieve a goal.
> The class hierarchy is in the nature of a comment;
> it has no run time significance.
> ---
> Trygve Reenskaug      mailto: trygver at ifi.uio.no
> Morgedalsvn. 5A       http://folk.uio.no/trygver/
> N-0378 Oslo             http://fullOO.info
> Norway                     Tel: (+47) 22 49 57 27
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150117/1ddbb64f/attachment.htm


More information about the Squeak-dev mailing list