Packages

There are 3 types of packages that change how the environment is treated.

Application

This is package main in Go. An application provides an entry point.

I may also limit access to some resources to the Application. For instance os access. In that case, os will provide a file system object that can be passed into any library or module that needs it, but it means that the application knows what's happening.

Library

A library is intended for re-use.

Only a library can access reflection and unsafe. Though not all libraries must.

Libraries have a very high testing and documentation burden. Libraries can only import libraries (not modules). Libraries must return specific errors.

Module

A module is intended to scope application logic. While a module may be shared between a few applications, it's not intended for wide, general purpose re-use.

Versioning

Package versioning is separate from source control versioning. A fully qualified version has Domain, Package, Major version, Minor version, Patch version and a file list.

The file list is sorted by name and includes the hash of each file. The packages form a cryptographic linked list (yeah, a blockchain) where each minor and patch version point to the previous. All the data is included in a package hash. Also needs to include a list of packages that it uses, their version and hash.

When releasing a patch version, the API tests from all previous versions in the minor branch must pass. The package interface cannot change. When releasing a minor version, all tests from all previous versions must pass, and the previous version must be compatible with the current version. This will allow some coercion though. A function that accepted a single value and now accepts a variadic is ok. Something that accepted a concrete type and now accepts an interface is ok. Something that returned an interface and now returns a concrete type that fulfills that interface is ok.

Major packages are really considered to be a separate package.

Version Collisions

This creates an issue. If an application tries to include packages A and B which both include C but A includes C3.2.1 and B include C3.1.2, this is not ok.

I think the best solution is to always use the highest minor version from any package included.

Bug Fix

One case that can break this is bug fixes.

If a bug in just in a test, we can issue a patch to the test. This requires listing the range of versions with the bug. Those tests will not be run in future versions.

If the bug is in the package that requires a few things. First, there needs to be a test that fails on the previous version and passes on the new version. In most cases a minor release will be required.

License

A fully qualified package must include a license. We can build a graph a license subsets and make sure that there are no license conflicts.

Security

This is implemented at a package level. Signatures are based on EigenTrust. So a user can place partial trust in a few base organizations and compute aggregate trust in any organization from there.

But trust isn't needed for all packages. Trust level required is computed from the state of the package.

Applications that don't access restricted resources don't require any trust.