Curious that it's a type error and not an attribute error. Feel like we should just try catch and just add typeerror to the list in addition to attribute error.... More pythonic anyway

Curious that it's a type error and not an attribute error. Feel like we should just try catch and just add typeerror to the list in addition to attribute error.... More pythonic anyway

That’s indeed curios and weird! Still, I have a question about this part of the code: why checking for one attribute in all the imported modules, don’t we know already that the modules we are looking for have “cloudsync” in their name?

I proposed a very quick-and-dirty fix; I can try to spend more time on it and make more elegant.

It's not necessarily the case that they will all have cloudsync in the name Anyone can write a new module and they can name it whatever they want

The same is valid for attribute names!

I am not totally sure I understand the point here. I guess we are looking for the "sub-packages" cloudsync-onedrive and cloudsync-gdrive here. Am I wrong? The best option, IMHO, would be to check the package name and/or author or even a sort of UUID or package identifier and have some naming rules if one wanted to write a package to work with cloudsync.

Let me know what's the best strategy to quickly fix this bug, and then we can work together on a better solution, if you want.
Cheers

__cloudsync__ is not an attribute exported by tensorflow, it's only used by cloudsync plugins. and it's a good way to identify modules that export the interface. the bug in tensorflow that causes it to be a typeerror is really a bug in how tensorflow exports their modules. it's ok, but changing to catch a type error is the right way to resolve this. module names is not helpful at all. there are already many modules that don't have cloudsync in the name that we know people are using.