"import ftrack_api" into nuke 12v1

[daans]

Hi all,

I running into a issue here, which I don't seem to be able to solve. Hopefully somebody can steer me into the right direction.

I developed a little python script with the ftrack_api. It works great when using it in a terminal (ubuntu 19.10). But when I try to use it in Nuke (Nuke 12v1) I get an error. It errors when importing the ftrack_api. I do run this WITHOUT ftrack-connect btw.

So when I open a terminal, type python, type import ftrack_api it works. But when I open nuke, open the script editor (I did add import sys, sys.path.append('/usr/local/lib/python2.7/dist-packages' to my init,py). I get the following error:

 

import ftrack_api

# Result: Traceback (most recent call last):

File "<string>", line 1, in <module>

File "/usr/local/lib/python2.7/dist-packages/ftrack_api/__init__.py", line 5, in <module>

from .session import Session

File "/usr/local/lib/python2.7/dist-packages/ftrack_api/session.py", line 29, in <module>

import arrow

File "/usr/local/lib/python2.7/dist-packages/arrow/__init__.py", line 3, in <module>

from .arrow import Arrow

File "/usr/local/lib/python2.7/dist-packages/arrow/arrow.py", line 19, in <module>

from arrow import util, locales, parser, formatter

File "/usr/local/lib/python2.7/dist-packages/arrow/parser.py", line 12, in <module>

from backports.functools_lru_cache import lru_cache # pragma: no cover

ImportError: No module named backports.functools_lru_cache

 

I also tried to set the $PYTHONPATH to point to the ftrack_api to see if that made any difference, but it didn't, same error.

What I do find strange is that when I add /usr/local/lib/python2.7/dist-packages/ftrack_api to my init.py it actually doesn't work (I would expect that to work instead of the whole dist-package folder).

 

So is it possible to import the ftrack_api inside nuke without using ftrack_connect? If so, any help would be great!

 

 

all the best,

 

Daan

 

 

[Lorenzo Angeli]

Hi @daans, Although I wouldn't suggest to install modules system wise (either installing on the user or in virtualenvs),
ftrack api can totally be imported and put to the use from within Nuke and without the connect support.

Looking at the error you are having :

ImportError: No module named backports.functools_lru_cache

seems some dependencies are not properly installed, or not picked up from Nuke itself.
But I'd say the latter if you can make them work from pure python shell.

As test I've been creating (under Linux Centos 7 , but should not make any difference for Ubuntu) a virtual environment as:

python -m virtualenv api-test -p python2.7 

(note, python2.7 is an alternative python built of 2.7.18 as C7 ships with 2.7.5 which is too old for the api to work)

and then activating the virtualenv and installing the api with : 

python -m pip install ftrack-python-api

started nuke (12.1v2) with and then from the Script editor:

import sys
sys.path.insert(0, '/home/ftrackwork/.venv/api-test/lib/python2.7/site-packages')

import ftrack_api
s = ftrack_api.Session() # note I've the my credentials in the environment variables

print s.query('Project').all()
> # Result: [<dynamic ftrack Project object 140663537353232>, <dynamic ftrack Project object 140663537353488>, <dynamic ftrack Project object 140663537353552>, <dynamic ftrack Project object 140663537353040>, <dynamic ftrack Project object 140663537353104>, <dynamic ftrack Project object 140663537353168>, <dynamic ftrack Project object 140663537353424>, <dynamic ftrack Project object 140663537353808>, <dynamic ftrack Project object 140663537353680>]

hope it helps.
L.

[daans]

Hi thanks for the quick reply!

After fiddling around a bit longer, I reinstalled the ftrack api on the user (not system wide) and I needed to downgrade arrow and that solved my issue! (v0.15.6 was installed, downgraded to 0.9.0 didn't test other versions).

 

 

Thanks!

 

Daan

[Lorenzo Angeli]

Hi @daans, so glad to hear you sorted it out!
if you happen to have any other issue, please let us know!
Cheers.

L.

[Guest]

I've seen this exact error where some tool imports it's own version of (some portion of) backports, which then masks (maybe "masks" is not the correct word since it's encountered first) the particular portion that we (or our dependencies need). I'm glad the re-installation/downgrading solved it since I don't have a great general solution to the issue.