Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
key_filename value from Collection.config and config file is not passed on connect to paramiko #1762
Python 3.6.5, Invoke 1.0.0, fabric 2.0.0, paramiko 2.4.1
First of all the argument is called
But the real problem is that either using it in
Here you see the
but initializing it from
Thanks for the report, just fixed the docs typo, and the rest I'll have to look at. Hoping it doesn't represent a design-level issue with the config system, but it might
EDIT: to clarify the latter, the config system ought to be merging between levels without issue, and as you saw,
This is absolutely a bug that needs fixing either way, since configuring one's default auth/cxn params is a top tier piece of functionality.
Looking at this now; yea, the debug log (which I hadn't looked at initially) definitely confirms the OP's suspicion that the overrides level is winning:
That comes after the per-project config file load line, which does show the user's desired value appearing there. So this has something to do with how we're populating the overrides layer, probably at the time when we take over from Invoke's default config stuff and add fabric-level specifics.
What's weird is that we have a big ol' block of tests around all the various config layer interactions, specifically aimed at
Notice how we're explicitly weaving in the 'Invoke config'. I'm guessing that this is too high-level and we're feeding in an explicit
Going to try writing some more focused tests in the Config test suite to expose whatever's really going on.
Also, looking at the code, I have a hunch this applies to all
Seems the proximate cause is some too-strict value checking in Fabric's extension of
Hrm, so yea first fix easy, second fix tho...harder, because overrides are what they are. No good way to say "actually merge this one key instead of overriding with it".
I'd bet most people giving
Given that the actual behavior (due to this bug) resulted in "CLI wins" anyways and nobody could be relying on "CLI merges with config", I'm thinking I'll just tweak the docs and say we meant this all along. Yes...clearly. steeples fingers