I can't seem to find the magic formula that lets me just update the packages that have changed and install new ones. If I use, say, fanr install -y -r http://repo.status302.com/fanr/ "*", I get, as expected, everything on the repo listed. Most of them are listed as something like this:

Engine [skip] 0.1 => 0.1

Fanr then, however, proceeds to download ALL of the packages, whether already installed at that version or not, and then proceeds, after all that is done, to install ALL of the packages. The "skip" thing doesn't seem to mean anything.

OK, so maybe install isn't the right subcommand. What are the other choices? Nothing seems to leap out, but maybe I can sculpt a query? I do fanr query -r http://repo.status302.com/fanr/ "*" and:

Engine
  A Gold Parser Engine
  0.1    (14-Apr-2015)

There doesn't appear to be any way to get a condensed listing (making it difficult to write a script that extracts the required information) and there doesn't appear to be any comparison to the current version installed anyway. No, for that I have to do fanr env "*" then manually compare the blocks for each installed pod against the blocks for each remote pod to find the ones which have changed. Which I would then have to list in a very long query to fanr install ….

So now I'm thinking that I'm maybe missing something in the query syntax, but I'm looking at that and not seeing anything that will help. Anything in there involving versions would require me to still hand-parse the not-very-parse-friendly output of the queries as far as I can tell, involving a minimum of two invocations of fanr, more likely three.

So, is there something I'm missing here? If not, would there be any room for an enterprising occasional Fantom user to hack in an "update" subcommand perhaps?

Very quickly, to get parsable data you could query the repository directly as it returns JSON:

pods := afButter::Butter.churnOut.get(`http://repo.status302.com/fanr/query?afButter`).body.jsonMap

which returns

{"pods":[
{
"pod.name":"afButter",
"pod.version":"1.1.4",
"pod.isScript":"false",
"pod.native.jni":"false",
"proj.name":"Butter",
"vcs.name":"Mercurial",
"build.host":"Sulaco",
"org.uri":"http://www.alienfactory.co.uk/",
"org.name":"Alien-Factory",
"pod.native.dotnet":"false",
"fcode.version":"1.0.51",
"pod.native.java":"false",
"vcs.uri":"https://bitbucket.org/AlienFactory/afbutter",
"repo.private":"false",
"pod.docApi":"true",
"build.user":"Slimer",
"tags":"system",
"build.ts":"2015-04-25T22:25:49.397+01:00 London",
"pod.native.js":"false",
"proj.uri":"http://www.fantomfactory.org/pods/afButter",
"build.platform":"win32-x86_64",
"pod.depends":"sys 1.0;inet 1.0;web 1.0;util 1.0",
"pod.docSrc":"true",
"license.name":"The MIT Licence",
"pod.summary":"A library that helps ease HTTP requests through a stack of middleware",
"build.compiler":"1.0.67"
}
]}

The list of commands are available on fanr::WebRepoMod:

Method   Uri                       Operation
------   --------------------      ---------
GET      {base}/ping               ping meta-data
GET      {base}/find/{name}        pod find current
GET      {base}/find/{name}/{ver}  pod find
GET      {base}/query?{query}      pod query
POST     {base}/query              pod query
GET      {base}/pod/{name}/{ver}   pod download
POST     {base}/publish            publish pod
GET      {base}/auth?{username}    authentication info

In terms of abstractions, update is really a layer above install (as install is defined today). Update requires querying your local library to build up a pod list, then querying that list of pods from the remote repo, check each version, and install ones out of date. I definitely agree we should handle it better, and probably best solution is new update command. Would definitely be good project for someone to try their hand a patch, doubt I will have time anytime soon (that Void return problem comes first when I have a bit of time)

As an aside, I often thought it'd be cool to have some sort of Pod Manager for Fantom.

It would essentially be a local file fanr repo that provides an implementation of Env. The env could search up the file system (from the current dir) looking for a build.fan. It would then make available all the pods listed in the depends list. Perhaps it could also auto-download / install to it's local repo, any pods it didn't have.

Then different projects could have dependencies on different versions of the same pod.