Reusability: Difference between revisions
no edit summary
(explain build manifesto since it's currently a red link) |
No edit summary |
||
| (9 intermediate revisions by the same user not shown) | |||
Line 1:
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
For programs which are not implemented as triple scripts but *do* adhere to the [[build manifesto]] (i.e. they use a triple script-based build system), 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 <code>GET</code> request to a user-visible URL).
Line 5:
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 the semantic versioning scheme and/or
* 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 things "right" with respect to the separation between
* In traditional systems, externally hosted 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
== See also ==
| |||