[squeak-dev] Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

Miguel Cobá miguel.coba at gmail.com
Tue Dec 14 21:46:01 UTC 2010


El mar, 14-12-2010 a las 15:24 -0600, Chris Muller escribió:
> Hi Miguel, working on your provocative prose again, I see..??  :-)

:) Well...

> It's doing really good, so you should transfer some of your focus to
> gaining a better understanding about what the other legacy formats are
> for.  MC is a SCM tool _complimentary_ to, not a replacement for, the
> legacy formats.
> 

But nobody is saying that, not me at least. Your original question and
the reason I joined the thread was:

Does Gofer support all legacy formats?  ChangeSets, SqueakMap,
Universes, Monticello, Monticello Configurations?

I said that in the design of gofer a decision was made and that it was
to only support monticello. I don't care a dime if installer or gofer
are part of squeak. Nor I'm proposing that any of them are part of
squeak. My point is that gofer doesn't try to do everything for
everyone. Kinda like Basecamp doesn't try to be MS Project, but even so
it has a lot of users.

> For example, I would not use MC-overrides to alter existing system
> methods.  It's easier to use a ChangeSet for that. 

That is clear to me and to many others too, again I said great majority
and not everyone. Of course there are uses for changesets, but there are
more uses for MC.

>  I know you
> probably never deviate from a standard Pharo system, but Squeak is
> about being a system that can be modified, and is.

I don't know what you mean here. Pharo can be modified just the same as
Squeak. 

> 
> SqueakMap is a package *catalog* that merely provides access to
> software and *resources* regardless of where or what format they're
> in.  MC or Metacello simply don't provide support for external
> resources.

Agreed. That isn't a problem for a lot of applications. And the fact
that map and sar files support external resources also isn't their
selling point, because they lack others needed as dependency support and
traceability. But that is other discussion.


> 
> Yes, "Monticello is the current de facto format for
> storing/publishing/sharing new code and new releases of packages."  No
> argument there.  Squeakers were using MC years before you busted onto
> the scene.  It's just that MC doesn't do all the things the "dodo"
> does, and nor should it because it's a different tool; a SCM tool.
> 

Exactly, and that is precisely the reason that Installer isn't "better"
that gofer just because "supports legacy formats". It is just a
different tool, with a different design and use case goal.

> HTH,
>   Chris
> 
> 
> 
> On Tue, Dec 14, 2010 at 2:01 PM, Miguel Cobá <miguel.coba at gmail.com> wrote:
> > El mar, 14-12-2010 a las 13:13 -0600, Chris Muller escribió:
> >> Does Gofer support all legacy formats?  ChangeSets, SqueakMap,
> >> Universes, Monticello, Monticello Configurations?
> >
> > Umm, how may people actually uses those legacy format (dead for me).
> > Apart from magma, I know of no other project that uses SqueakMap and
> > MCM for publishing new versions. Even less for universes and the
> > changesets are from the time when Squeak was part of disney.
> > As good as they could have been, they are, for all practical purpouses,
> > dead. Monticello is the current de facto format for
> > storing/publishing/sharing new code and new releases of packages. This
> > legacy argument is good in theory but the reality is, they are going the
> > way of the dodo.
> > Universes, I can't remember the last time it had working packages for
> > the current squeak/pharo image.
> >
> > Lets accept it. For good or bad, monticello packages are the way to go,
> > and gofer desing is around this observation.
> >
> >
> >>
> >> I have nothing against aesthetics and compactness, but functionality
> >> is a important criteria to me than lines of code.  I want an installer
> >> utility to just work for me, not be a work of art to admire.  :-)
> >>
> >> If Gofer only supports a subset of the Installer types, maybe
> >> Installer could be stripped of its functions that overlap with Gofer
> >> and employ Gofer for those parts.  That way, "Installer" can also
> >> support Gofer scripts..?
> >>
> >>  - Chris
> >>
> >>
> >>
> >> On Mon, Dec 13, 2010 at 2:23 PM, Bernhard Pieber <bernhard at pieber.com> wrote:
> >> > Hi Ken,
> >> >
> >> > If you ask... ;-)
> >> >
> >> > Am 13.12.2010 um 18:21 schrieb Ken G. Brown:
> >> >> I for one do not want to see Installer disappear.
> >> >> Can anyone explain to me what advantage GoFer has over Installer?
> >> >> Seem to me they are doing more or less the same thing.
> >> > I like Gofer better than Installer for the following reasons:
> >> > - Gofer has an active maintainer, the original author still maintains it.
> >> > - Lukas writes top quality Smalltalk code IMO. I find the code cleaner. (That, of course, may just be my personal preference.)
> >> > - Gofer is much smaller than Installer - 640 lines of code versus 1703 - thus the image would be smaller if we replaced Installer with Gofer.
> >> > - At the same time Gofer has more functionality which I find quite useful, committing, fetching and pushing. See http://www.lukas-renggli.ch/blog/gofer for a short description.
> >> > - Installer has a lot of code which is rarely used.
> >> > - Installation code for packages which are compatible between Squeak and Pharo could be the same in many cases, which I find less confusing.
> >> > - This brings Squeak and Pharo closer together again, which would be a good thing IMO.
> >> >
> >> > Enough reasons in my opinion. Of course, reasonable people might disagree. ;-)
> >> >
> >> > Cheers,
> >> > Bernhard
> >> >
> >>
> >
> > --
> > Miguel Cobá
> > http://twitter.com/MiguelCobaMtz
> > http://miguel.leugim.com.mx
> >
> >
> >
> >
> >
> 

-- 
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx






More information about the Squeak-dev mailing list