Importing `pandas` for example with `generalimport("*")` fails
Mandera opened this issue · 5 comments
Because pandas is importing pyarrow for example to check its __version__ and listening for ImportError.
Simple solution of course is to not use wildcard, but there's always a risk you want to have pyarrow as an optional dep yourself and you are using pandas, in which case it's a real issue
Might be possible to check where the import came from by using inspect.stack. Then only handle imports if they came from where generalimport was called or a child to it. stack isn't as slow as I feared, around 752 usec per loop
Maybe generalimport() should create an instance with each call so that you can enable and disable the names you just configured.
Every name registering now should take a scope parameter. The scope parameter will be an additional check on whether to handle missing imports or not.
It should be under the hood, nothing that the user will see, it should be intuitive.
I think the scope should be the folder in which generalimport was called.
Then the scope check will pass if the file, where the import was made, is directly or indirectly inside the folder.
Will need to create methods to list all instances again, but this time it should be a separate class because there should always only be one instance in sys.meta_path
New class ImportCatcher, holds names and a single scope.
Store all instances in cls list.
Should the importer iterate all instances on import or should instances update the importer?
What happens if a name has multiple scopes? If any of the scopes trigger then it should trigger
| Question | Answer |
|---|---|
| If names are removable should we remove it from sys.modules too? | No, if it's already imported we shouldn't touch it |
| Import matches multiple scopes? | Pair import with first Catcher which has a scope match |
| Should Catcher be disableable? | Yes |
| Should Catcher keep track of added names? | Yes |
| Should Importer store names? | Just store Catchers |
| Should names be removable? | Yes, in Catchers |
| Should scope be changeable? | Can change _scope but lets not encourage it |