Konstantin Maslyuk

@Jason Porath I found quite fine running running unit and functional tests on test projects right on production server. It is quite easy to construct any context with ftrack_api and release it after tests finished. In worst case you will got a bunch of test entities on test project that no one cares. so feel free to: @pytest.fixture def session(): return ftrack_api.Session() @pytest.fixture def context(request, session😞 context = session.create('Folder', {'parent_id': ..., 'project_id': ..., 'name': ...}) def finalizer(): session.rollback() session.delete(context) session.commit() request.addfinalizer(finalizer) return context The better approach is to running tests on staging ftrack server that should have relative fresh database snapshot from production, that is much more complex.

Hi, you could try now pip install ftrack-python-api==2.2.0rc1 or https://bitbucket.org/ftrack/ftrack-python-api/branch/backlog/threading/story#diff that is indented to solve threading issue.

Logging an uncaught exception Traceback (most recent call last): File "\\somewhere\ftrack_connect_pipeline\util.py", line 28, in exceptHookWrapper method(*args, **kwargs) File "\\somewhere\ftrack_connect_pipeline\ui\widget\actions.py", line 308, in _addRecentAction recentActions = self._getRecentActions() File "\\somewhere\ftrack_connect_pipeline\ui\widget\actions.py", line 276, in _getRecentActions if not self._isRecentActionsEnabled(): File "\\somewhere\ftrack_connect_pipeline\ui\widget\actions.py", line 255, in _isRecentActionsEnabled session = ftrack_connect_pipeline.util.get_thread_session() File "\\somewhere\ftrack_connect_pipeline\util.py", line 153, in get_thread_session thread._ftrack_session = get_session() File "\\somewhere\ftrack_connect_pipeline\util.py", line 140, in get_session auto_connect_event_hub=False File "C:\Program Files (x86)\ftrack-connect-package-1.1.2\common.zip\ftrack_api\session.py", line 268, in __init__ self._discover_plugins(plugin_arguments=plugin_arguments) File "C:\Program Files (x86)\ftrack-connect-package-1.1.2\common.zip\ftrack_api\session.py", line 1362, in _discover_plugins self._plugin_paths, [self], plugin_arguments File "C:\Program Files (x86)\ftrack-connect-package-1.1.2\common.zip\ftrack_api\plugin.py", line 120, in discover **selected_keyword_arguments File "C:\Program Files (x86)\ftrack-connect-package-1.1.2\resource\hook\resolver.py", line 140, in register resolver File "C:\Program Files (x86)\ftrack-connect-package-1.1.2\common.zip\ftrack_api\event\hub.py", line 406, in subscribe subscription, callback, subscriber, priority File "C:\Program Files (x86)\ftrack-connect-package-1.1.2\common.zip\ftrack_api\event\hub.py", line 453, in _add_subscriber priority=priority File "C:\Program Files (x86)\ftrack-connect-package-1.1.2\common.zip\ftrack_api\event\subscriber.py", line 13, in __init__ subscription File "C:\Program Files (x86)\ftrack-connect-package-1.1.2\common.zip\ftrack_api\event\subscription.py", line 15, in __init__ self._expression = self.parser.parse(subscription) File "C:\Program Files (x86)\ftrack-connect-package-1.1.2\common.zip\ftrack_api\event\expression.py", line 94, in parse 'Failed to parse: {0}. {1}'.format(expression, error) ParseError: Failed to parse: topic=ftrack.location.request-resolve and source.user.username="xxxxxx@xxxxxxx.com". Some times i encounter exceptions when initialize a Session some time i got exception when working with locations, the real exception here is completely obscured. Could i suggest to do logging.exception() before raising another exception in exception handler?

PR already there

hm, another issue under py3 (Pdb) pp sys.version_info sys.version_info(major=3, minor=6, micro=8, releaselevel='final', serial=0) (Pdb) bool(server_location.resource_identifier_transformer) True (Pdb) server_location.resource_identifier_transformer Symbol(NOT_SET)

It look like the problem is that ftrack_api.Session._request.post() have no timeout in ftrack_api.Session.call(), so control never returned to main thread to test EventHub connection

Hi, all. I making ftrack services with docker containers with auto restart and i found that if you disconnect a network with docker, event hub will just attempt to to reconnect 30 times * 10 seconds and then just sleep. Event EventHub.connected will be truth, i think it is because of unlogged error in EventHub.disconnect()

@Lorenzo Angeli finally i still think that schema loading code is not optimized, a lot of unnecessary work occur inside single process. I could suggest pull request for caching schema.

My python version and platform: v2.7.17:c2f86d86e6, win32 You right, i cant reproduce my issue with clean cases: list(concurrent.futures.ThreadPoolExecutor(3).map(apply, [ftrack_api.Session] * 3)) nither: pip install git+https://bitbucket.org/ftrack/ftrack-connect-pipeline.git git+https://bitbucket.org/ftrack/ftrack-connect-maya-publish.git https://bitbucket.org/ftrack/qtext/get/0.2.1.zip PySide ftrack-python-legacy-api python -c "import ftrack_api, pyblish.api, ftrack_connect_pipeline.publish as p, ftrack_connect_pipeline, ftrack_connect_pipeline.application_plugin as g; from QtExt import QtWidgets;import urllib;import logging;logging.basicConfig(level=logging.INFO);G = type('G', (g.BaseApplicationPlugin, ), dict(get_plugin_information=lambda s: {}));a = QtWidgets.QApplication([]);d = {};exec(urllib.urlopen('https://bitbucket.org/ftrack/ftrack-connect-maya-publish/raw/808a548e1a4f409890c864f3234a7381bdd1b590/resource/application_hook/register_scene_asset.py').read(), d);g=G('68e9a0ac-355d-11ea-8ce6-000c29ff458b');import ftrack_connect_pipeline.shared_pyblish_plugins;ftrack_connect_pipeline.shared_pyblish_plugins.register(); pyblish.api.register_plugin(type('Y', (pyblish.api.ContextPlugin, ), dict(order=pyblish.api.CollectorOrder+0.01, process=lambda self, context: context.data.update(dict(ftrack_entity=ftrack_api.Session().get('Context', context.data['ftrack_entity']['id'])))))); d['register'](g.api_session); g.register_assets();ftrack_connect_pipeline.register_plugin(g);p.Publish(g).open()" (that is a midnight fun). I will investigate my modifications to ftrack_connect_pipeline. My issue occur when user clicks on workflow, it is added to recent actions in async way that cause (with my modification) new session to be created, then pyblish cycle create session to renew current entity.

Hello, i have a case where two ftrack sessions initialized simultaneously from different threads, with overall time spent of 20 seconds, here is profiling result: 200561 function calls (158003 primitive calls) in 21.062 seconds Ordered by: cumulative time ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 20.759 20.759 c:\Users\kalem\OneDrive\Work\home\dev\test\monorepo\python\inhouse\ftrack\__init__.py:56(__init__) 1 0.002 0.002 20.758 20.758 C:\Users\kalem\.virtualenvs\test\lib\site-packages\ftrack_api\session.py:76(__init__) 1 0.001 0.001 12.834 12.834 C:\Users\kalem\.virtualenvs\test\lib\site-packages\ftrack_api\session.py:1405(_load_schemas) 1 0.636 0.636 12.833 12.833 C:\Users\kalem\.virtualenvs\test\lib\site-packages\ftrack_api\session.py:1365(_read_schemas_from_cache) 5 0.000 0.000 12.202 2.440 c:\python27\lib\json\__init__.py:193(dumps) 5 1.557 0.311 12.201 2.440 c:\python27\lib\json\encoder.py:186(encode) 24534 2.515 0.000 10.643 0.000 c:\python27\lib\json\encoder.py:417(_iterencode) 26576/24534 2.605 0.000 8.129 0.000 c:\python27\lib\json\encoder.py:288(_iterencode_list) 64684/24524 5.341 0.000 5.621 0.000 c:\python27\lib\json\encoder.py:341(_iterencode_dict)

Hello, I may missed something, but I think it would be convenient to have kanban board with notes with ability to filter and switching root as in table views. My particular case it's to consider notes been completed in date range. Thank you.

poetry also install and run with ftrack-connect from that branch well. i knew that pip isn't robust, but case with Jinja2 3.0.0a1 was first case i encountered. Maybe there was incorrectly published package that i got into my pip cache and it was broke my installations a couple of weeks.

i finally got it working in docker with following Dockerfile Dockerfile

And when i attempted to do a clean install inside docker, i got following: with pip==19.3,20 docker-centos7.txt

I had installed ftrack_connect without any issue (but i still have a lot of wheels in pip's cache on my windows host) Although i expected implementation of build_ext command so i may not encounter ImportError for resource module when installing in development mode. First time i encountered that error i decided that it is a bug. If i: diff --git a/setup.py b/setup.py index 39990d9..fbaf6b5 100644 --- a/setup.py +++ b/setup.py @@ -261,2 +261,3 @@ configuration = dict( 'build': Build, + 'build_ext': Build, 'build_resources': BuildResources, Then "pip install -e ./ftrack-connect && python -m ftrack_connect" does not produce an error. It may be proper to implementing resources as setuptools.Extension - i don't know. build_ext.txt