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
>
