You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The presence of the Python script complicates CI as it requires having Python installed, typically another copy of TensorFlow, with the associated library-path issues etc.
It would be nice if this functionality (i.e. the call to the relevant C++ functionality) could be moved to Haskell.
The text was updated successfully, but these errors were encountered:
Making converter.py use Tensorflow copy in the submodules would be possible, but would require building more of Tensorflow than we currently do; TFLite can be built using cmake but the rest requires Bazel, which requires Java.
On the other hand, converter.py currently just uses the system-installed Tensorflow (absent specific measures to prevent this), which need not even be the same version as the embedded one. Fixing this might by itself be a reason to swallow the Java dependency.
The latest state: converter.py must remain a Python script, because the relevant API is only available in Python (as shown in my comment above). However, we do now build a full Tensorflow copy from the embedded TF submodule, including the Python wheel, and register that in a virtualenv that converter.py can then use. Hence we do not need any system-installed TF any more.
The presence of the Python script complicates CI as it requires having Python installed, typically another copy of TensorFlow, with the associated library-path issues etc.
It would be nice if this functionality (i.e. the call to the relevant C++ functionality) could be moved to Haskell.
The text was updated successfully, but these errors were encountered: