Package manager

Local installs, a manifest and a lockfile, content hash verification, and the marketplace client for the network registry.

Venutian's package manager installs code you point it at, remembers what you installed, and can prove later that none of it has changed.

Install from a path or an archive

shell

venutian install ../geometry-tools

Copies the package into venutian_packages/geometry-tools/ inside your project and records the dependency in venutian.json, creating that file on the first install:

output

Installed 1 package(s):
  + geometry-tools -> venutian_packages/geometry-tools

json

{
  "name": "myproj",
  "version": "0.1.0",
  "dependencies": {
    "geometry-tools": {
      "kind": "path",
      "location": "../geometry-tools"
    }
  }
}

An archive works the same way: .zip, .tar, .tar.gz, and .tgz are all accepted.

shell

venutian install ./geometry-tools.tar.gz

Install under a different name with --name:

shell

venutian install ../geometry-tools --name geo

Reinstall everything

With no argument, install reads venutian.json and installs every dependency it lists, transitively, resolving the dependencies of your dependencies too. It detects a cycle and tells you rather than looping.

shell

venutian install

See what is installed

shell

venutian list

output

  geometry-tools

Remove a dependency

shell

venutian uninstall geometry-tools

output

Removed geometry-tools.

Lock and verify

lock writes a content hashed lockfile from what is actually installed right now:

shell

venutian lock

json

{
  "geometry-tools": {
    "content_hash": "e61702f02f56ff0a7bb17a9b425eeb48d45c00db231b497c52c496df526af5e5"
  }
}

verify checks every installed package's contents against that lockfile:

shell

venutian verify

output

OK   geometry-tools, matches lockfile

Anything that has drifted since the lockfile was written is called out by name, not silently accepted.

What this half does not do

Local install, list, lock, and verify are deliberately narrow: they read and write venutian.json and venutian.lock.json, copy files, and hash content. None of them talk to a network on their own. Trust is not a default; a dependency is a real folder you chose, sitting inside your project where you can open it.

The marketplace client

A second, network facing half of the CLI dispatches to the registry instead of your local disk:

shell

venutian search <query> [--limit N] [--page N] [--json] [--registry-url <url>]
venutian outdated [--json]
venutian update [<name>] [--json] [--dry-run]

search queries the network registry by name. outdated diffs your project's marketplace dependencies against the registry's latest versions that have not been yanked. update updates one named dependency, or every outdated one with no argument, and --dry-run shows what would change without changing it.

Installing a package by name rather than by path routes to the same marketplace client:

shell

venutian install <name>[@version] [--json] [--registry-url <url>] [--save]

venutian install tells a local path or archive apart from a registry name by the shape of the argument: a real local directory or archive is installed directly, and anything else is looked up on the marketplace. Publishing your own package to the registry runs through the same marketplace layer.

Library updates reach you without checking by hand

Once a day, the update notifier installed alongside venutian compares the libraries recorded at install time against the registry's manifest and names every new library and every updated one directly in your terminal, with the one line upgrade command for each. See updates and notifications for how to read that, and how to turn it off.

Where to go next

Standard library for what already ships with Venutian, no install required.
Modules for how an installed package's files are actually pulled into your program with use.
Updates and notifications for the notifier that watches the registry for you.