Using shotgun_api3_registry

[mikeboers]

We are using an internal module to connect to Shotgun. A stub should be created that will continue to work without this.

[ProjectGuerilla]

I'm interested in sgactions and can't find any info online about "dhotugn_api_registry". It looks, from the code, like a wrapper that mimics a standard "sg" call through the API.

Is it as simple as checking for everywhere that you have replaced a std call with the registry call and refactoring? There could be a check on import (try/except) to use your calls if available or a standard call if not but I don't know what would break.

I'd be happy to do the coding if I "get it" but if you have some magik going on under the hood I couldn't even test without access to the registry.

Let me know what you think

[mikeboers]

shotgun_api3_registry is a simple module that provides a connect function to construct shotgun_api3.Shotgun instances from a name. All of my tools use it so that their source does not need to be modified in order to run them in a different environment (e.g. a testing server, or your facility).

The one at WesternPost looks like https://gist.github.com/mikeboers/5536498 (but with real URLs and keys).

So, we can either document that "feature", or implement a fallback (which I actually wrote before I even started using the registry for just this scenario):

def get_shotgun(name):

    import os, sys, shotgun_api3

    if 'SHOTGUN_API3_ARGS' in os.environ:
        return shotgun_api3.Shotgun(*os.environ['SHOTGUN_API3_ARGS'])

    try:
        import shotgun_api3_registry
    except ImportError:
        raise RuntimeError("Set $SHOTGUN_API3_ARGS or provide shotgun_api3_registry.connect."
    else:
        return shotgun_api3_registry.connect(name)

sg = get_shotgun(__name__)

Which of those do you prefer?

[ProjectGuerilla]

I understand the second method immediately so I am inclined in that direction - I'm sure I could get to the essence of the registry if I took time to really study it and the concept seems solid.

Looking at the sample you provided I'm guessing 'xxx' for the secret script keys for Shotgun but the magik-methods will take a little ruminating.

In some odd sense, both of your options seem like they are important IF this software is getting much traction in the community. If it hasn't taken off then I'd personally opt for the quicker option just to get underway so I can test your package.

From the few pages of code that I have looked at so far it seems that it might be less work to include shotgun_registry.py in the module and document it. This would work "out of the box" as opposed to having to find every instance of creating a SG object in the code and inserting a call to get_shotgun() instead.

If you could provide me with a slightly longer description of the purpose and function of the registry I'll take the time to figure out what it is doing and see how to integrate it into the project/document it.

How does that sound?

[mikeboers]

Tell you what. I'll take a look through the various "sg*" projects here, and make sure that the function I wrote above (or something very similar) will work. Then I'll implement it across the board, and document that you can either provide a SHOTGUN_API_KEYS environ variable, or implement the shotgun_api3_registry.connect() API.

I really don't want to put anyone in the situation where they must modify some of the source (i.e. an included shotgun_api3_registry.py) in order for it to work, because upgrades could be pretty nasty.

[ProjectGuerilla]

Less work for me :-)
I have been using configparser and config files to hold the user-edit data - no reason that the registry couldn't be easily modified to read a config file. This would allow the site specific data to be separated from the updates pretty elegantly.

If you want any help, just let me know. I hesitate to send you off on a mission when I'm not even sure yet how I might implement the tool.

[mikeboers]

This tool is done, and actually deployed to the PyPi as v1.0.1.

See https://sgactions.readthedocs.org/en/latest/#shotgun-api-keys for the environment variables.

There are still some sticking points (e.g. the project that tickets are opened against is hard-coded), but it should at least run at this point.

[ProjectGuerilla]

Thanks!