SG-Jira bridge - python 2.7?


I’m trying to set up the sg-jira bridge. Do you have use python 2.7 even though it’s no longer supported? I tried to install shotgun_api3 w/2.7 and got this message:

DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.

Collecting shotgun_api3
ERROR: Could not find a version that satisfies the requirement shotgun_api3 (from versions: none)
ERROR: No matching distribution found for shotgun_api3

So I tried with python 3.7, but getting import error with

Traceback (most recent call last):
File “sg-jira-bridge/”, line 13, in
from shotgun_api3 import Shotgun
File “/Users/bonnietai/venv/lib/python3.7/site-packages/shotgun_api3/”, line 1, in
from shotgun import (Shotgun, ShotgunError, ShotgunFileDownloadError, Fault,
ImportError: cannot import name ‘Shotgun’ from ‘shotgun’ (/Users/bonnietai/venv/lib/python3.7/site-packages/shotgun/

Even though I’ve installed both Shotgun and shotgun packages.



Hi Bonnie!

First, welcome to the community! :partying_face:

You currently have to use Python 2.7 for both the JIRA bridge and the Shotgun event daemon. We haven’t ported these components yet to Python 3.

The error you have seen during the import of shotgun_api3 in the JIRA bridge when using Python 3.7 is due to the fact that the JIRA bridge’s requirements.txt file has pinned the version of the Python API to 3.0.39, which wasn’t Python 3 compliant.

We’re still porting our code to Python 3. Our current focus is on the Toolkit components. JIRA Bridge and Event Daemon are going to be ported at the tail end of the port. The reason Toolkit is prioritized over these two components is that the bridge and the daemon run with a version of Python that our clients have complete control over.

On the other hand, for software like Maya and Nuke, our clients are at the mercy of whatever versions of Python the software vendors decides to ship with. We do not want clients to be blocked from upgrading to a more recent version of a product because we do not support Python 3. It’s looking like most of the software vendors are going to be shipping support for both Python 2 and 3 this year, but there’s no guarantee how long they will. Plus, certain DCCs, like Blender, only support Python 3.




Ah, I see, thanks JF!

I changed my venv to use python 2.7 and it works now. However, now I’m running into this error when I run sg-jira-bridge/

File “/Users/bonnietai/Shotgun/venv/lib/python2.7/site-packages/jira/”, line 57, in raise_on_error
r.status_code, error, r.url, request=request, response=r, **kwargs)
jira.exceptions.JIRAError: JiraError HTTP 400 url:
text: The query parameter ‘username’ is not supported in GDPR strict mode.

That seems to be addressed in the latest version of … is there something on the jira side I need to do? We are using jira cloud.


1 Like

Hi @bonosmo,

This error is due to recent changes to the Jira Cloud REST API. You will need to update to sg-jira-bridge v0.2.2 to pick up the fix.

Once you have the code downloaded, make sure you update the packages in your environment as well by running:
pip install --upgrade -r /path/to/sg-jira-bridge/requirements.txt

Hopefully that will solve your problem.

1 Like

That worked, thanks Ehsan!

I’m getting close! I’m trying to test the bridge in this part of the quickstart guide:

However, I can’t find the " Sync In Jira checkbox" on the Task (per the directions). Can someone put up a screenshot, or specific instructions on how to get that to show up?


1 Like

Hi Bonnie,

I’m glad to hear you’re getting farther on this. The “Sync In Jira” field is not an out of the box field and you need to add it to the task entity yourself. There are a few other fields you will need to add as well.

Try going to this step in the quick start guide and make sure the fields are all set up correctly. If you need help setting up new fields, you can follow the steps here.

One more thing to keep in mind: When you’re adding a field to Shotgun make sure you’re using the Display Name from the table in the instructions. SG adds the sg_ part to the field name automatically.

1 Like

Ah, yes, that’s what happened, I created sg_sync_in_jira, but it automatically concatenated “sg_” to the field code, so that’s why it could find it. I created a new field, without “sg” in it and now I can add it properly.

I found it now, but now I have question about webapp; I ran:

python --settings --port 9090

then: foreground

but the killed both processes. When I tried to run the command again, I have a

socket.error: [Errno 48] Address already in use

Did I not kill the process properly?

Thanks for your help!

1 Like

Turned out I didn’t actually kill the process =)

However, I’m at the testing step, and I’ve added a task in shotgun, but nothing is happening in jira. Also, I’m not sure where I should be configuring which jira project to add to?


1 Like


Just seeing this post for the first time, but HI! Welcome to the forums! Hope you’re well!

Love your profile photo =)

:wave:t4: :wave:t4: :wave:t4:

1 Like


Here are a few things to look into to try and figure out what the problem is:

  1. The first step is to make sure your SG project is set up to sync with the correct Jira project. In this step you would have already set up two field on your project entity: Jira Sync URL and Jira Key. You need to make sure you’ve set these two values on your project.
  2. On the task you created, is Sync In Jira checked?
  3. When you run your event daemon in the foreground, it will print out logs about the events it is processing. After creating your task (or checking the Sync In Jira box on an existing task) have a look at the output of the event daemon to make sure it processed the event and it forwarded it to the sg_jira_event_trigger plugin. If this hasn’t happened, the problem is with your event daemon setup
  4. If the event trigger is functioning properly, the next step is to look at the sg-jira-bridge server ( output and make sure it is receiving the request and processing it correctly. You can set the verbosity of the logging in

Hopefully as you go through those steps you’ll find something that will help you get the bridge up and running.


Hi Tannaz!!! hope this finds you well too!

LOL … yeah, those were the good old days huh? :smile: Miss those lunches with you by the lagoon!


Hi Ehsan,

There might be something wrong with the ShotgunEventDaemon setup. Can you explain the error messages?

When I run ./ foreground

I get this output:

INFO:engine:Loading plugin at /Users/bonnietai/Shotgun/sg-jira-bridge/triggers/
INFO:engine:Loading plugin at /Users/bonnietai/Shotgun/sg-jira-bridge/triggers/
Traceback (most recent call last):
File “./”, line 1083, in emit
smtp.connect(self.mailhost, port)
File “/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/”, line 317, in connect
self.sock = self._get_socket(host, port, self.timeout)
File “/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/”, line 292, in _get_socket
return socket.create_connection((host, port), timeout)
File “/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/”, line 575, in create_connection
raise err
error: [Errno 61] Connection refused
Logged from file, line 776
CRITICAL:engine:Did not find a registerCallbacks function in plugin at /Users/bonnietai/Shotgun/sg-jira-bridge/triggers/

but it does start logging in events from the Shotgun Database:

INFO:engine:Last event id (######) from the Shotgun database.

I have the version of sg_jira_event_trigger from the git repo, am I supposed to change it? There is a “registerCallbacks” function in, just not in the which is what it is complaining about.

1 Like

Hi Bonnie,

I’m sorry for the late reply. This thread fell off my radar. I’m hoping that you have gotten this working by now but just in case…

Both of these errors can be safely ignored for a test setup.

The first one is due to a configuration issue with the SMTP server. If you want to resolve the problem you’ll need to populate the email section of shotgunEventDaemon.conf file with valid values. You can choose to ignore this error if you’re just testing things. But you will not receive any log emails.

The second is due to the fact that the event daemon expects the triggers folder to only contain python files with valid plugins in them. You can resolve this by removing the from the jira bridge trigger folder, or you can move the file to a separate directory and point the event daemon to that location. Again, the trigger should have been registered and operational in your setup already. The daemon is just complaining about the file and skipping it.

If you’re not seeing the behaviour you expect, it’s likely due to another issue. Let me know if you still haven’t gotten it working and what you’re running into and I can try and help you get set up.


1 Like