[squeak-dev] Installer cleverness (was Re: The Inbox: Installer-Core-tpr.434.mcz)
forums.jakob at resfarm.de
Sat Aug 31 23:41:08 UTC 2019
Oh, another dependency management facility. Is this specific to Monticello
repositories or can it install from other sources as well? I am wondering
whether or not much of this code rather belongs in InstallerMonticello.
It seems unclear to me where you are supposed to maintain your project's
dependency tree with this one. In Squeak trunk or in your project's
repository? Unless your project's dependency tree listing is admitted into
trunk, you need your own Installer subclass or extension and make sure to
have it loaded before loading the actual project. Similar to loading the
latest Metacello before being able to use the Metacello install snippets
from GitHub projects.
On the positive side, this code in Installer is arguably easier to
understand than the one in Metacello.
Am Sa., 31. Aug. 2019 um 23:43 Uhr schrieb Chris Muller <asqueaker at gmail.com
> On Sat, Aug 31, 2019 at 12:30 PM tim Rowledge <tim at rowledge.org> wrote:
>> It's a whole parallel set of ways to load packages that wasn't mentioned
>> in the pbwiki doc I was originally looking at and stealing from. It means
>> of course, another tranche of stuff to try to describe ;-)
>> Take a look at, for example,
>> `Installer new merge: #osProcess`
>> a) I'd say adding a class side #merge: to avoid the #new is worth it
> b) way easier to tell someone to use than the whole open monticello, find
>> the repository, click on... etc etc
>> c) possibly easier to describe even than
>> `Installer ss package: 'OSProcess'; install`
>> and its relatives, since you don't need to know where packages live once
>> they are specified.
> Yes, I like and use it too.
>From the author timestamps it also looks like you wrote it, Chris.
>> d) it does make another place that needs checking as part of release to
>> make sure the package definitions are up to date etc
> Not as part of the release process, but simply regular development of the
> packages affected by new dependency requirements. These are logical
> package hierarchies (i.e., just the names and repositories, no notion of
> physical "versions" anywhere), so its only when a developer enhances a
> package to suddenly need an all-new dependent that they would update its
> package-definition in Installer.
It seems to offer at least in part what Metacello does with its baselines
(dependency names and locations), but omits its configurations (stating
versions of the packages). If the dependency versions cannot be locked
down, things might break in the future if dependencies change in a
backwards-incompatible manner. Can the versions be pinned?
>> I have read the swiki page (http://wiki.squeak.org/squeak/6366) but
>> honestly it's just too succinct to work for me. More explanation would
>> certainly help!
> I just looked at it and it seems to all be there -- perhaps as the author
> it's hard for me to understand which parts need more explanation. A lot of
> things which express a somewhat complex concept require more than one
As a developer and knowing Monticello I think I understood what is written
on that page.
@tim: What specifically did you miss or not understand?
@Chris: May I suggest you put your name in the example section ("Seamless
partition ...") on that page? Because now the text reads "I", but without
knowing that the things prefixed with Ma are yours, one does not know who
The sudden switch from Installer to MyInstaller, without first defining
what the latter is or where it comes from, is a little confusing though.
Facilities like copyLocalVersionsToRemoteFor:... don't belong into a class
called "Installer" IMHO. This is rather a Monticello utility.
In which cases would you suggest that newcomers use this mechanism for
their project? What are the use cases, compared to Metacello, or SqueakMap,
since the wiki page claims that "It is not intended to replace any [of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev