Distinguish test package dependencies versus library package dependencies

[matthewhammer]

Motivating example

Consider this scenario:

I have two packages:

• BigTest is a testing library developed to script long-running tests with a DSL
• BigMap is a data structure library developed for simple databases that get really large

Each package has a test suite, in its test subdirectory; when master advances for this package repo, we want to run CI using this test suite.

BigTest solving a problem that the test suite of BigMap needs to solve. So, the test suite of BigMap depends on BigTest.

BigMap is a service that BigTest tests, as a regression test for its own revision management. So, the test suite of BigTest depends on BigMap.

Unless we distinguish library dependencies from test dependencies (e.g., cargo for Rust does this), we have a problem: There is a cyclic dependency between these two packages, apparently.

Today

Today, vessel packages conflate the dependency information of package's library code and that of its test suite code, in the sense that there is only one place to specify this information, even though the dependency structure we want is really more fine-grained.

This issue proposes that this information be distinguished.

Proposal

I propose we distinguish library and test packages (two kinds of packages):

• Libraries depend on other libraries.
• Test suites depend on libraries.
• By default: Libraries do not depend on test suites (because test suites are either not possible to name as packages themselves, or they are distinct with distinct names from the corresponding library package).

Initially, we need not name or import test suite packages.

But we do need to identify their dependencies, and permit them to include more than the libraries that they test.

[kritzcreek]

I'm tracking this in #26 which is a little more general. Thanks for the description, this definitely provides lots of motivation for the design we'll come up with.