New post
0

Using the sgtk Python module from a project [PATCH]

Avatar
Ian Thompson
None
Follow

Let's say we have a project:

  • /path/to/project

With a pipeline configuration:

  • /path/to/project/sgtk

A while ago we tried setting the PYTHONPATH to include the project's linked core python directory:

  • export PYTHONPATH=/path/to/project/sgtk/install/core/python

But then this happens when we try to initialize:

>>> import sgtk
>>> tk = sgtk.sgtk_from_path("/path/to/project")
tank.errors.TankError: Location metadata file '/path/to/project/sgtk/install/core/python/sgtk/config/core/install_location.yml' missing! Please contact support.

I thought this was some expected behaviour, but somehow the path is being compounded, and this seemed wrong.

I dug around and found that install/core/python/sgtk/__init__.py is a proxy and sets the environment variable TANK_CURRENT_PC before importing the "real" sgtk library. Removing this made it work, but I'm sure it's there for a reason.

Looking further I realised it sets TANK_CURRENT_PC to the "current_folder", which is:

  • /path/to/project/sgtk/install/core/python

This is not a pipeline configuration and that seems to be why it breaks (it is within one though). If instead we go up a few more levels we do get a pipeline configuration:

  • /path/to/project/sgtk

So I changed the code to strip those extra directories and it works!

I've attached a tk-core patch. To apply:

  • git am 0001-Fix-to-allow-inclusion-of-project-pipeline-configs-i.patch

Do you think this makes sense as a fix? Could it be incorporated into a core release? We'll keep the patch on hand locally anyway and continue using this to see if it introduces subtle problems, but so far it's going well.

Thanks,

Ian




0001_Fix_to_allow_inclusion_of_project_pipeline_configs_i.patch
Date Votes

10 comments

  • 0
    Avatar
    Permanently deleted user

    Hello Ian!

    Thanks for sending this and sorry to hear you are having problems! It certainly looks like a bug - however strangely enough it seems to work on my machine if I quickly try to set it up. (This may be why we haven't enocuntered it before). Let me create a bug ticket in our ticket system, try to reproduce it locally and I'll get back to you with more info. We'll definitely include your fix in the next core release, thanks for sending across! More info as I have it :)

     

  • 0
    Avatar
    Permanently deleted user

    Ian! I just pushed your change to the master branch of Core. Will go out in the next core release!

  • 0
    Avatar
    Ian Thompson

    Great stuff! Thanks Manne!

  • 0
    Avatar
    Ian Thompson

    Hi Manne,

    I have another fix to the same file.

    The create project script creates files named "core_Linux.cfg" , "core_Windows.cfg" and "core_Darwin.cfg"

    When importing the proxy modules, however, the use of "core_%s" % sys.platform yields "core_linux2.cfg" on Linux and "core_darwin.cfg" on Mac OSX

    Switching sys.platform to platform.system() fixes this issue, yielding  "core_Linux.cfg" and "core_Darwin.cfg" correctly. I have not tested for Windows but the documentation (http://docs.python.org/2/library/platform.html#platform.system) would imply it should work too.

    Thanks,

    Ian

     

  • 0
    Avatar
    Permanently deleted user

    Indeed! Thanks for highlighting this! We used platform.system() early on (hence we got stuck with the strings Linux, Windows and Darwin) and at a later point refactored to use sys.platform - looks like we forgot to add our usual little mapper dictionary here! Sincere apologies! I'll fix right away.

    FYI - the reason we did the switch is that the implementation of platform.system() on mac and linux wraps around uname, meaning that it is susceptible to the interrupted system call signal issues you can get sometimes in QT. Basically, this means that in any application where Python is integrated together with QT, platform.system() may randomly raise an IOError rather than returning what you want. Which can lead to some seriously weird behaviour! :)

  • 0
    Avatar
    Permanently deleted user

    I just pushed v0.14.41 of the core with a single bug fix for this! Thanks for finding and helping to fix!

    Manne 

  • 0
    Avatar
    Ian Thompson

    That's a good thing to know regarding platform.system(), thanks for the info. And thanks for getting that fix in so quickly, pulling down now.

    Ian

  • 0
    Avatar
    Ian Thompson

    I have another patch to this file. Although we can easily work around this for the time being I thought I should pass it along anyway.

    Don't include newlines when reading linked core entry

    If the linked core file (core_Linux.cfg) is edited by hand a newline
    is often introduced by the editor. The code that reads this file uses
    readline() which preserves the end-of-line character(s) if present and
    these then get looked up as part of the filename. Stripping them first
    solves this.

  • 0
    Avatar
    Alan Dann

    Hi Ian,

    Thanks for the patch - it looks good so I've applied it to core and it will get released in the next core release.

    Thanks again

    Alan

  • 0
    Avatar
    Ian Thompson

    Thanks Alan!

Please sign in to leave a comment.