Hi Jakob,
 
Oh, another dependency management facility.

I don't think of it that way.  They're just documentation in literal arrays which happen to facilitate a few use cases.
 
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.

I would rather deprecate every subclass below Installer that currently resides in trunk.  Sake and Universe can extend Installer subclasses in their own packages, if anyone is still using them.  Installer's responsibility is to help users get stuff installed, so IMO we should simplify Installer to have just what we settled on for our core SCM tool, and let it advance with things like these more expressive package-definitions and stuff.
 
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?

It's entirely up to you.  There's generally no opposition if you want to include your own project-definition in Installer-Core (trunk).  The cost (one method returning an Array literal) is infinitesimal relative to the potential brought by easy access to your system.  Squeak's most core projects which are generally useful, like FFI and OSProcess, are certainly useful to document in Installer-Core (trunk).
 
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.

Yes.  I organize my public packages that work together like Magma and Maui into MaInstaller.  But then, I have a set of private Maui applications which I put into a deeper subclass, MaCommercialInstaller.

That way, IDE configuration is equally seamless with one's own private projects as for public ones -- for example, the "mc revisions" and "origin" setup is done by configuring MC repositories, I can just say:

    Installer addLocalRepositories

it's enumerates all loaded projects, calculates and adds their local repository to each WorkingCopy.
 
On the positive side, this code in Installer is arguably easier to understand than the one in Metacello.

It's all positive, I hope!  :)   It really is just about advancing Installer.  It can't replace Metacello.  The two serve different purposes.

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?

Yes, Installer>>#primMerge:from: first checks for an exact match on the specified "packageName" (e.g., as a version name) before choosing the #highestNumberedVersionForPackageNamed:.

But it hasn't been used that way.  Just imagining the idea of starting to add a bunch of version-specific methods -- it would really dilute the efficiency of its presence.  Not worth it, IMO, especially when we already have Metacello and SqueakMap to do that.  But, it's a rational behavior and a nice potential backstop for a possible special needs case...
 

 
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.

Okay, thanks for the feedback.  I'll take a look.
 

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]"?

Even if you use Metacello, setting up these literal arrays can be very useful in helping to configure your repositories on your WorkingCopies.  Especially if you use Personal SqueakSource, but even if you don't, the #addLocalRepositories example above can be really nice.   It ensures there's one for your local directory, one for remote repository and, if it finds a Personal SqueakSource running on localhost, the http entry for it (so that revisions and origin can work)).  That's three per package -- can you imagine having to do that manually?!

Regards,
  Chris 



Kind regards,
Jakob