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 <p...@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.henri...@gemtalksystems.com> wrote: > > > On 10/22/16 12:04 AM, p...@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 >