torb update

update is the one command that moves locked versions forward. Without arguments every package of project.lock.trb may move; with names, only those move and everything else stays where the lock has it. It is also how a lock is written the first time for a project.trb whose dependencies were written by hand.

Synopsis#

torb update [<package>...]   Resolve again: every package, or the named ones
  --accept-capabilities      Take versions that touch more than the locked ones did
  --offline                  No network: indexes from the cache's copies
  --project <directory>      The project whose workspace to update

What it does#

The changes are printed one line a package, ~ for a new version, + and - for a package that joins or leaves the graph, and every package that is not in the cache is installed:

$ torb update --project app
  ~ acme/json 1.0.0 -> 1.1.0
installed acme/json 1.1.0
1 package installed, 0 of them already in the cache

An update that gains a capability#

Every release in the index says what it touches by its own imports (docs/design/RELEASE.md section 7.8). An update that takes a version touching more than the locked one did is refused, and says what it would gain, until --accept-capabilities says it is wanted:

$ torb update --project app
  acme/json 1.1.0 -> 1.2.0 gains files
error: the update gains capabilities: nothing was changed. `--accept-capabilities` takes them

Pitfalls#

A requirement is a ceiling update never crosses. ^1.2.0 never becomes 2.0.0; a new major is a new requirement, written with torb add.

Examples#

The gain taken on purpose, for one package, with everything else left where the lock has it:

$ torb update acme/json --accept-capabilities --project app
  ~ acme/json 1.1.0 -> 1.2.0, touches files
installed acme/json 1.2.0
2 packages installed, 1 of them already in the cache

Related#

• torb add - a new dependency, or a new requirement for one.
• torb install - the packages of a lock, without resolving anything.
• project.lock.trb - what update writes.