-
Notifications
You must be signed in to change notification settings - Fork 22
Introduce 'requires' #114
Introduce 'requires' #114
Conversation
Also add rudimentary implementations and error handling in Prepare().
mklp("baz 1.0.0", "baz/qux"), | ||
), | ||
}, | ||
"require impossible subpackage": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This brings us back to another variant of a familiar question - if an unimported dep is constrained in the manifest, does that constraint still come into effect?
I think it's pretty clear in this case, though: having the requires list is basically equivalent to having an import path, and these are both emerging from the same manifest (so we can assume the same user has control over it), thus the constraint should be applied. And because deps can't express requires, we don't have the same transitivity problem as with normal imports.
Also touchup docs and remove project root prefix from mklp() call.
This was far easier than I expected. Requires really are the equivalent of imports, just taken from a manifest instead of static analysis.
Current coverage is 76.92% (diff: 82.75%)@@ master #114 diff @@
==========================================
Files 23 23
Lines 3400 3428 +28
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 2611 2637 +26
- Misses 599 600 +1
- Partials 190 191 +1
|
This doesn't introduce any new failure types, or change any of the existing ones. That means we're leaving it on the tool to figure out if a given package-related failure is due to a real import, or a require. This is fine for now, though in the future if we end up wanting to do any kind of lineage tracking, we might need more. |
Introduce 'requires'
This introduces the notion of a 'required' package:
This is a root-only capability: listing required packages is, thus, a
RootManifest
method.Prepare()
validation testsAddresses #42