Change vendor imports so that it will use system wide modules if the the import from vendor directory fails.

[omadjoudj]

This will help maintaining pyinvoke package in most distro that does not accept bundled libraries (in my case Fedora).

The plan is to clear vendor/ and let pyinvoke use system provided modules.

[codecov-io]

Current coverage is 91.92% (diff: 48.14%)

Merging #412 into master will decrease coverage by 1.23%

@@             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          

Powered by Codecov. Last update 753e487...3327964

[bitprophet]

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 / .spec / whatever, which just does rm -rf invoke/vendor && (pip|yum|dnf|etc) install <all the deps>?

[omadjoudj]

Just curious, are you planning to pair this with a build script / .spec / whatever, which just does rm -rf invoke/vendor && (pip|yum|dnf|etc) install ?

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.

[bitprophet]

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!