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 <mailto: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
<mailto:dale.henri...@gemtalksystems.com>> wrote:
On 10/22/16 12:04 AM, p...@highoctane.be
<mailto: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
<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
<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
<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
<https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client>
[3]
https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston
<https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston>
[4] https://github.com/hpi-swa/smalltalkCI#smalltalkci
<https://github.com/hpi-swa/smalltalkCI#smalltalkci>--- [5]
https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston
<https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston>
