Catalog is a ���temporary solution��� for a problem that is already 2 years around��� is not what I would like, and certainly is far from perfect. 
One of this days I will come with a solution that can allow baselines, for example���

Esteban

On 22 Oct 2016, at 18:37, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:

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, phil@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.henrichs@gemtalksystems.com> wrote:



On 10/22/16 3:09 AM, Esteban Lorenzano wrote:

On 22 Oct 2016, at 10:56, Dimitris Chloupis <kilon.alios@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