Comments (7)
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
from sgactions.
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?
from sgactions.
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?
from sgactions.
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.
from sgactions.
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.
from sgactions.
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.
from sgactions.
Thanks!
from sgactions.
Related Issues (2)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sgactions.