Programs implemented as triple scripts are expected to vendor their dependencies. In other words, maintainers should distribute third-party code in the same source tree as the project's own code. If using a version control (e.g. Git), the third-party modules (i.e. the content of those modules—not pointers to their entry on some external package repository) are to be checked in to version control system.
For programs which are not implemented as triple scripts but *do* adhere to the build manifesto, program dependencies MUST be either vendored as well OR provide some means of obtaining ALL third-party code necessary to build the program in a single-shot (preferably with a single HTTP GET request to a user-visible URL).
This strategy differs from the workflows that have arisen regarding contemporary "modern" package managers (which generally operate using pointers and semantic versioning). There are several reasons for this:
- Programmers have demonstrated some combination of a poor grasp of semantic versioning or a poor execution in adhering to it
- By embedding the contents of dependencies into the same source tree or providing a single-shot means of obtaining all third-party dependencies, it's much easier for maintainers to get the separation between code acquisition and building "right" and for that separation to remain clear for those downstream
- In traditional systems, dependencies might disappear, but in the world of triple scripts, the strategy resembles the philosophy of LOCKSS, which can be viewed as an insurance policy against the disappearance of dependencies, but actually goes further than that, by elevating the "resilient" path into the standard workflow
- The systems devised for managing packages in a pointer-based scheme exhibit a complexity that haven't clearly proven to be worth their costs
NB: Even though the triple script approach does not work in terms of semver pointers, programmers ARE encouraged to continue using semantic versioning—it's just that the triple script approach eschews operating on pointers in lieu of direct use of the module contents.
There is no tooling at this time for actually managing packages.