I'm wrong ... I hadn't followed the whole chain. Although as I've
mentioned in another post, the Catalog is wired to ConfigurationOf and
is Pharo-specific ... A common "project load spec" could be plugged into
the CatalogBrowser framework and provide ConfigurationOf and BaselineOf
support ...
Dale
On 10/22/16 8:31 AM, p...@highoctane.be wrote:
CatalogProvider projectNamed: 'QuickAccess'
is doing that already.
Or I am mistaken?
Phil
On Sat, Oct 22, 2016 at 3:50 PM, Dale Henrichs
<dale.henri...@gemtalksystems.com
<mailto:dale.henri...@gemtalksystems.com>> wrote:
On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
On 22 Oct 2016, at 10:56, Dimitris Chloupis
<kilon.al...@gmail.com <mailto:kilon.al...@gmail.com>> wrote:
We need some easy to use gem-style installer on the command line.
we have it:
./pharo Pharo.image get Seaside3
will load seaside into your Pharo.image
this is catalog based, of course (there is no magic there, if you
want an easy way to install things, you need a centralised
repository).
Esteban
ps: there are a lot of perks like that people ignores… what we
actually need is a better documentation system :)
Esteban,
I really think that the catalog could benefit by a first class
objects like the TDProjectEntry and MetacelloProjectLoadSpec ...
these would be objects directly created and maintained by the
project developers themselves. The objects would be used for
custom build scripts, smalltalkCI builds, catalog loads, etc. ...
oh and if it was a Metacello class, it would be usable cross
platform (Squeak, Pharo, GemStone, etc.)
As a coincidence, I have been planning on talking on this subject
at the upcoming Smalltalks conference ... The working title for
the talk is "Dangerous Liaisons: Smalltalk, Files and Git" ...
Dale
