Hi everyone,
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@gmail.com
:
On Sat, Aug 31, 2019 at 12:30 PM tim Rowledge tim@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 reading...
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 "I" is.
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 them]"?
Kind regards, Jakob