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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190901/e20f8842/attachment.html>