Consider a guardrail for the fact that -f changed to load config, not fabfile #1823
The following code (
Run the above code:
on Ubuntu 18
will yield the following exception
The exception disappears when I remove the line
Windows 10, Ubuntu 18
The text was updated successfully, but these errors were encountered:
I think the problem is you're using
That's the proximate cause, the root cause is I think an actual bug where we must not be stripping out module objects from Python-style config files. I thought this got fixed but it must be an outstanding PR or something...hrm, can't find. Say hi to pyinvoke/invoke#556 ...
That said, unless you modified your example from the real problem case: you shouldn't need
This (getting tripped up by the change in what
Hrm, I don't see a foolproof way to guard against the highest level problem (loading a fabfile as a config file) because it's technically plausible a user could do anything short of literally including a module object, in a config file. E.g. random stuff like:
from requests import get some_key = get("http://my/api/server").json()
will work because
What this means is, it's not possible to really detect the "oops, gave a fabfile to a config file" scenario. I think the best we can possibly do is just catch this particular wrinkle (user put a module in there, which will never ever work) and warn about that itself; maybe putting language in just in case it is this problem.