This is what christophe is doing in cargo.

Stef

Looks like we are on the same wavelength but...

Look how this is done in PHP with Composer:

- simple Json file

- declares repositories

- requires and requiresdev

- uses semver versions

so, 'composer install' will fetch and install deps.

composer update will update deps.

composer.json

{

�� �� "name": "zendframework/skeleton-application",

�� �� "description": "Skeleton Application for ZF2",

�� �� "license": "BSD-3-Clause",

�� �� "keywords": [

�� �� �� �� "framework",

�� �� �� �� "zf2"

�� �� ],

�� �� "homepage": "http://framework.zend.com/",

�� �� "repositories": [{

�� �� �� �� "type": "vcs",

�� �� �� �� "url": "https://github.com/RobLoach/firephp-core"

�� �� �� �� }],

�� �� "require": {

�� �� �� �� "php": ">=5.5",

�� �� �� �� "zendframework/zendframework": "~2.5",

�� �� �� �� "zendframework/zftool": "dev-master",

�� �� �� �� "firephp/firephp-core": "dev-master",

�� �� �� �� "videlalvaro/php-amqplib": "^2.5"

�� �� },

�� �� "require-dev": {

�� �� �� �� "snapshotpl/zf-snap-event-debugger": "1.*",

�� �� �� �� "zendframework/zend-developer-tools": "dev-master",

�� �� �� �� "phpunit/phpunit": "4.8.*"

�� �� }

}

In the JS Ecosystem, eg. bower.json

{

�� "name": "adsdaq",

�� "homepage": "https://github.com/anais-it/adsdaq",

�� "authors": [

�� �� "Philippe Back <phil@highoctane.be>"

�� ],

�� "description": "adsdaq-frontend",

�� "main": "",

�� "moduleType": [],

�� "license": "Adlogix",

�� "private": true,

�� "ignore": [

�� �� "**/.*",

�� �� "node_modules",

�� �� "bower_components",

�� �� "vendor/bower_components",

�� �� "test",

�� �� "tests"

�� ],

�� "dependencies": {

�� �� "angular": "~1.4.7",

�� �� "restangular": "~1.5.1",

�� �� "lodash": "~3.10.1",

�� �� "angular-route": "~1.4.7",

�� �� "angular-spinner": "~0.8.0",

�� �� "angular-bootstrap": "~0.14.3",

�� �� "typeahead.js": "~0.11.1"

�� }

}

So, basic module names in deps and semver.

The st code you show is more cryptic.

Is there a sweet spot ?

Ston is a great format and is Json compatible if we are careful (meaning I can actually use vim and json syntax checkers plugins)

St code is indeed more powerful but it leaves a lot of people in the dust with configurations.

What do you think?

Phil

On Sat, Oct 22, 2016 at 3:17 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:

On 10/22/16 12:04 AM, phil@highoctane.be wrote:

We need some easy to use gem-style installer on the command line.

Phil,

Since I am not really familiar with ruby, I'm not sure what you mean by "gem-style installer on the command line"?

Depending upon what you mean, I think I agree:)

For GsDevKit_home[1], I have arranged for bash scripts that can be used for building both stones and clients for GemStone. Here are the example scripts for Tugrik[2]:

  # Create Tugrik stone
  createStone -u http://gsdevkit.github.io/GsDevKit_home/Tugrik.ston -i Tugrik -l Tugrik Tugrik 3.3.0

  # Create Tugrik Pharo5.0 client
  createClient -t pharo tugrik -l -v Pharo5.0 -z $GS_HOME/shared/repos/Tugrik/.smalltalk.ston

The Tugrik.ston file is a tODE object looks like the following[1] when materialized (basically a Metacello load script with additional info): �� ^ TDProjectSpecEntryDefinition new ������ baseline: 'Tugrik' ���������� repository: 'github://dalehenrich/Tugrik:master/repository' ���������� loads: #('default'); ������ installScript: ' ���������� project install --local --url=http://gsdevkit.github.io/GsDevKit_home/MongoTalk.ston ���������� project clone --https --local Tugrik'; ������ postLoadScript: 'mount @/sys/stone/dirs/Tugrik/gsdevkit/tode /home tugrik'; ������ status: #(#'inactive'); ������ locked: false; ������ yourself Their are fields for comments and a project url as well ... obviously other fields are possible ... the cool thing about this is that is a specification for a load rather than a Smalltalk load expression ... which means the repository can easily be re-targetted or the loads list changed, etc. Since Pharo doesn't have tODE:), I leverage the SmalltalkCI[4] configuration file for Tugrik[5], which looks like this: �� SmalltalkCISpec { �� #loading : [ ������ SCIMetacelloLoadSpec { ���������� #baseline : 'Tugrik', ���������� #load : [ 'CI' ], ���������� #onWarningLog : true, ���������� #directory : 'repository', ���������� #platforms : [ #gemstone, #pharo ] ������ } �� ], �� #configuring : [ ������ SCIGemStoneServerConfigSpec { �������� #defaultSessionName : 'Tugrik', �������� #platforms : [ #gemstoneClient ] ������ } �� ] ��} Very similar information, but has the advantage of being usable in GemStone, Squeak and Pharo ... I have an option for creating stones using a SmalltalkCI configuration file as well ... I've been thinking that I could add a MetacelloProjectLoadSpecification class to Metacello that is meant to be passed around as an object in STON format that combines the good bits of the TDProjectSpecEntryDefinition with the good bits of the SCIMetacelloLoadSpec and be available in GemStone, Pharo and Squeak ... then you'd just send #load to the object to trigger the install ... Is there anything in the "gem-style installer on the command line"that I'm missing? Am I completely off-base? Dale [1] https://github.com/GsDevKit/GsDevKit_home#open-source-development-kit-for-gemstones-64-bit- [2] https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client [3] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston [4] https://github.com/hpi-swa/smalltalkCI#smalltalkci--- [5] https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston