Lazy loading of shared libraries.

[gabrieldemarmiesse]

Fixes #855

I don't know how to make a test for that though. If possible we need to check that an so isn't loaded when doing import tensorflow_addons.

[seanpmorgan]

This LGTM thanks for the enhancement @gabrieldemarmiesse! @tensorflow/sig-addons-maintainers any issues with this?

[fsx950223]

Override __getattribute__ method may a better solution.

[gabrieldemarmiesse]

@fsx950223 thanks for the review! Can you expand on why it may be a better solution ?

[fsx950223]

No need to modify the original code by this way。
For example,

    return _activation_ops_so.addons_gelu(x, approximate)

Rather than

_activation_so.ops.addons_gelu(x, approximate)

[gabrieldemarmiesse]

I see what you mean, it's clever :)

Though i'm more in favor of having explicit code rather than having smart code. It's more maintainable and readable.

[Squadrick]

LGTM

[seanpmorgan]

Thanks again @gabrieldemarmiesse !

[AlexWang1900]

HI!
I am using this fix in tfa-nightly-0.8.0.dev20200205
on Kaggle Notebook , (TF2.1 latest docker)

!pip install tfa-nightly
import tensorflow_addons as tfa

I got this :

ImportError                               Traceback (most recent call last)
<ipython-input-12-8e92e93ce06e> in <module>
----> 1 import tensorflow_addons as tfa

/opt/conda/lib/python3.6/site-packages/tensorflow_addons/__init__.py in <module>
     19 
     20 # Local project imports
---> 21 from tensorflow_addons import activations
     22 from tensorflow_addons import callbacks
     23 from tensorflow_addons import image

/opt/conda/lib/python3.6/site-packages/tensorflow_addons/activations/__init__.py in <module>
     15 """Additional activation functions."""
     16 
---> 17 from tensorflow_addons.activations.gelu import gelu
     18 from tensorflow_addons.activations.hardshrink import hardshrink
     19 from tensorflow_addons.activations.lisht import lisht

/opt/conda/lib/python3.6/site-packages/tensorflow_addons/activations/gelu.py in <module>
     17 
     18 from tensorflow_addons.utils import types
---> 19 from tensorflow_addons.utils.resource_loader import LazySO
     20 
     21 _activation_so = LazySO("custom_ops/activations/_activation_ops.so")

ImportError: cannot import name 'LazySO'

[gabrieldemarmiesse]

@seanpmorgan do you have an idea of what can be causing this?

[seanpmorgan]

@seanpmorgan do you have an idea of what can be causing this?

Hmmmm this is puzzling. So as a sanity check here is a notebook using today's nightly without that issue:
https://colab.research.google.com/drive/1kK9on1C31gy7_PyTqHg4B6XrFs39d2EC

Could you provide the full docker image name of what you're using @AlexWang1900 . I'm thinking this is related to #987 since I see no reason this is happening from the python side (no circular import, inits look correct, etc.)

I tried to test this myself but conda still doesn't have a TF2.1 version so perhaps it was built from source in this docker image.

[AlexWang1900]

@seanpmorgan
it can be reproduced by running one kaggle notebook with option in settings,docker: latest availible

it is with TF2.1,so I think the docker image you can find it here:
kaggle docker image

Building a new image
./build
Flags:

--gpu to build an image for GPU.
--use-cache for faster iterative builds.

Running the image
For the GPU image:

Run the image built locally
docker run --runtime nvidia --rm -it kaggle/python-gpu-build /bin/bash

Tensorflow custom pre-built wheel
A Tensorflow custom pre-built wheel is used mainly for:

Faster build time: Building tensorflow from sources takes ~1h. Keeping this process outside the main build allows faster iterations when working on our Dockerfiles.
Building Tensorflow from sources:

Increase performance: When building from sources, we can leverage CPU specific optimizations
Is required: Tensorflow with GPU support must be built from sources
The Dockerfile and the instructions can be found in the tensorflow-whl folder/.

[seanpmorgan]

@AlexWang1900 thanks for the info. So I tried this in a GPU kaggle kernel and did not get the same error as you did:
https://www.kaggle.com/seanpmorgan/testtfa/

As expected when trying to run a custom-op we get the issue in #987 issue, but importing tfa and using other parts of it should work fine. Is there something different about my kernel than yours?

[AlexWang1900]

@seanpmorgan
I run it again and it works fine now ! many thanks!!!!
there should be no difference between your kernel and mine.
The only difference is the tfa version ,yesterday it came with tfa-nightly-0.8.0.dev20200205
today it is tfa-nightly-0.8.0.dev20200206