Pointer? Sent from the road
> On Oct 22, 2016, at 11:39, stepharo <[email protected]> wrote: > > This is what christophe is doing in cargo. > > Stef > > > >> Le 22/10/16 à 17:29, [email protected] a écrit : >> 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 <[email protected]>" >> ], >> "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 >>> <[email protected]> wrote: >>> >>> >>> On 10/22/16 12:04 AM, [email protected] 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
