Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Change vendor imports so that it will use system wide modules if the the import from vendor directory fails. #412
Current coverage is 91.92% (diff: 48.14%)
@@ master #412 diff @@ ========================================== Files 21 21 Lines 1930 1968 +38 Methods 0 0 Messages 0 0 Branches 329 330 +1 ========================================== + Hits 1798 1809 +11 - Misses 93 120 +27 Partials 39 39
Follow-up on #204 I take it? :D thanks!
This is an interesting reversal of my earlier assumption from that ticket, re: what a common solution might have been - namely to prefer global when present, with vendored as a fallback. In this case, you're preferring vendored, falling back to global.
I think that's good, because it means the only time the vendor copies will be skipped is when the installer/packager is explicitly choosing to forego the vendoring (& is thus implicitly responsible for ensuring dependencies are compatible versions). In that situation I'd assume the installer/packager knows what they're doing (vs a random user not realizing that installing some conflicting dependency is going to break their Invoke.)
Just curious, are you planning to pair this with a build script /
Dec 12, 2016
added a commit
this pull request
Dec 12, 2016
Yes (close enough), the only issue I think of is if the vedorized library is forked from upstream, in that case the changes should be merged upstream or downstream package.
Of course. IIRC my vendored copies are untouched aside from occasional hacks required to be vendorized, or (in the case of fluidity, though this was years ago so I'd hope it's released now) unreleased-but-public commits.
If you identify spots where that isn't the case, certainly let me know!