We Keep Coding

Flask: Address already in use, regardless of port

so I'm pretty new to Flask and i've been following a tutorial but I have been getting a strange problem. I have the following code, a python3 script, launched in atom with the hydrogen package enabled and jupyter. I have the virtual environment running in the background in a terminal.
from flask import Flask
app = Flask(__name__)
if __name__ == '__main__':
app.run(debug=True)
So obviously the script is very basic and it's just used to see if i can connect to localhost, however when running it (through Hydrogen) I get the following error:
Serving Flask app 'main'
Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
Running on http://127.0.0.1:5000
Press CTRL+C to quit
Restarting with stat
Traceback (most recent call last):
File "/home/uses12/.local/lib/python3.10/site-packages/ipykernel_launcher.py", line 17, in
app.launch_new_instance()
File "/home/uses12/.local/lib/python3.10/site-packages/traitlets/config/application.py", line 977, in launch_instance
app.initialize(argv)
File "/home/uses12/.local/lib/python3.10/site-packages/traitlets/config/application.py", line 110, in inner
return method(app, *args, **kwargs)
File "/home/uses12/.local/lib/python3.10/site-packages/ipykernel/kernelapp.py", line 666, in initialize
self.init_sockets()
File "/home/uses12/.local/lib/python3.10/site-packages/ipykernel/kernelapp.py", line 307, in init_sockets
self.shell_port = self._bind_socket(self.shell_socket, self.shell_port)
File "/home/uses12/.local/lib/python3.10/site-packages/ipykernel/kernelapp.py", line 244, in _bind_socket
return self._try_bind_socket(s, port)
File "/home/uses12/.local/lib/python3.10/site-packages/ipykernel/kernelapp.py", line 220, in _try_bind_socket
s.bind("tcp://%s:%i" % (self.ip, port))
File "/home/uses12/.local/lib/python3.10/site-packages/zmq/sugar/socket.py", line 232, in bind
super().bind(addr)
File "zmq/backend/cython/socket.pyx", line 568, in zmq.backend.cython.socket.Socket.bind
File "zmq/backend/cython/checkrc.pxd", line 28, in zmq.backend.cython.checkrc._check_rc
zmq.error.ZMQError: Address already in use
Upon looking online, a possible solution was to specify the port in the app. parameters, however no matter what port I specify it ALWAYS says that the address is already in use, leading me to believe that there is some deeper issue. I've done a check to see what services are using those ports and it's always just two instances of python3, I guess because Flask is set to debug. I'm completely lost. Can anyone help? Thanks so much.

403 Forbidden response from podio API using pypodio2

I ask this question having run out of ideas - I assumed I was doing something stupid but even if I am I can't figure out what... I'm new to python having drifted away from coding 10 years ago but I was reasonably proficient once :-D I've written a python script to query a google CSE and search for relevant items, and the idea is that it will check a Podio materials list to see if they are already listed there. So at the moment all I want to do is authenticate with Podio and grab items so I can query them in my app.
I'm trying to connect to the Podio API using the prescribed method in the docs (and in questions here, and everywhere else I have looked)
At this point literally all this script is doing is this except for the credentials replaced with the actual strings, just in case I was missing some python variable madness.
import pypodio2
from pypodio2.api import OAuthClient
c = OAuthClient(
"<myappID>",
'<myAPIkey>',
'<myusername>',
'<mypassword>'
)
I'm using pythonanywhere as a sandbox and I am running the script from a bash console, I get this
16:26 ~/mysite $ python apitest.py
Traceback (most recent call last):
File "apitest.py", line 15, in <module>
'Splat_100'
File "/home/Trebuchet/.local/lib/python2.7/site-packages/pypodio2/api.py", line 13, in OAuthClient
api_key, api_secret, domain)
File "/home/Trebuchet/.local/lib/python2.7/site-packages/pypodio2/transport.py", line 41, in __init__
urlencode(body), headers=headers)
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 2135, in request
cachekey,
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 1796, in _request
conn, request_uri, method, body, headers
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 1701, in _conn_request
conn.connect()
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line 1358, in connect
sock.connect((self.host, self.port) + sockaddr[:2])
File "/usr/local/lib/python2.7/dist-packages/httplib2/socks.py", line 496, in connect
self.__negotiatehttp(destpair[0], destpair[1])
File "/usr/local/lib/python2.7/dist-packages/httplib2/socks.py", line 457, in __negotiatehttp
raise HTTPError((statuscode, statusline[2]))
httplib2.socks.HTTPError: (403, 'Forbidden'
The password, key etc are correct. The username is correct. The clientID is correct. So I must be missing something that is obvious to people used to working with APIs. Mustn't I? Thanks :)

Free accounts on PythonAnywhere can only access http(s) sites that are on our whitelist. If the site you're using has a publicly documented API, send a link to it to PythonAnywhere support (support#pythonanywhere.com) and we'll consider add it to the whitelist.

Google Cloud App Engine Flexible Python 2.7 Env Errors starting new threads

I know just enough devops to be dangerous. I've successfully deployed a VERY simple python flask app to App Engine that basically publishes received post data as a message to PubSub. It is almost identical to Google's sample code to do so. Only difference is it uses a service account I push with the app repository to access PubSub to circumvent this issue.
Works very well so far, but I've started seeing a very small number of errors around starting a new thread in threading.py:
1)
Traceback (most recent call last):
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 33, in grpc._cython.cygrpc._spawn_callback_async
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 24, in grpc._cython.cygrpc._spawn_callback_in_thread
File "/usr/lib/python2.7/threading.py", line 736, in start
_start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread
2)
Traceback (most recent call last):
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 33, in grpc._cython.cygrpc._spawn_callback_async
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 24, in grpc._cython.cygrpc._spawn_callback_in_thread
3)
Traceback (most recent call last):
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 33, in grpc._cython.cygrpc._spawn_callback_async
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 33, in grpc._cython.cygrpc._spawn_callback_async
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 24, in grpc._cython.cygrpc._spawn_callback_in_thread
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 24, in grpc._cython.cygrpc._spawn_callback_in_thread
File "/usr/lib/python2.7/threading.py", line 736, in start
File "/usr/lib/python2.7/threading.py", line 736, in start
I have 2 questions, in order of importance:
This is an app that basically needs 100% uptime in order to not lose data (not confident the clients attempt retries if there is an error on my server side). Are these errors internal to how App Engine is managing my app's resources, and not resulting in errors handling actual requests? How can I determine if I ever responded with an HTTP error/didn't successfully handle a request? I don't see any errors in my nginx logs...is that the place I need to look to see if anything failed?
Is there a way I can fix this error?

https://github.com/GoogleCloudPlatform/google-cloud-python/blob/master/pubsub/google/cloud/pubsub_v1/publisher/client.py#L143
it looks like publisher.publish(topic_path, data=data) is an async operation, returning a concurrent.futures.Future object
Have you trying calling the Future's result()? https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Future.result
This will block until the future object is successful, fails, or timesout.
You could then forward that result as your HTTP response.
Hopefully, the result object will give you more information about the error.

Ended up changing the methodology a bit. Instead of posting a pubsub message then having dataflow ingest through GCS to BigQuery I decided to stream directly into BQ using the BigQuery python client. Updated dependencies for the python flask app to:
Flask==1.0.2
google-cloud-pubsub==0.39.1
gunicorn==19.9.0
google-cloud-bigquery==1.11.2
and I am no longer seeing any of those exceptions. It's worth noting that I'm still using a service account .json credentials file in the same directory as the app source, and I'm creating the BigQuery client with
bq_client = bigquery.Client.from_service_account_json(BQ_SVC_ACCT_FILE).
For anyone else with similar issues I'd recommend updating your dependencies (esp any Google Cloud client libraries) and create the Client you need from a local service account credentials file. I attempted to use the inherited Compute engine environment credentials (basically the default project compute engine service account) but that was less stable than pushing up an actual credential file and using that locally. However...assess your own security needs before doing the same.

Timeout error when uploading video to Vimeo through their API

I have a Python script that takes advantage of the latest Vimeo API (https://developer.vimeo.com/api/) to upload some videos to my Vimeo account.
Here is what, in a slightly simplified form, the script basically does:
from vimeo import VimeoClient
vimeo = VimeoClient('my_token_here')
uid = vimeo.upload('/path/to/file.mov')
When file.mov is 3MB or less everything works fine and the file is successfully uploaded. However, for larger files I get a timeout error:
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/home/fabio/.virtualenvs/venv/src/vimeo/vimeo/uploads.py", line 79, in __call__
return do_upload()
File "/home/fabio/.virtualenvs/venv/src/vimeo/vimeo/uploads.py", line 70, in do_upload
self.upload_segment(upload_uri, _range, video_data, filetype or 'mp4')
File "/home/fabio/.virtualenvs/venv/src/vimeo/vimeo/uploads.py", line 135, in upload_segment
body=data, headers=request_headers)
File "/home/fabio/.virtualenvs/venv/lib/python2.7/site-packages/tornado/httpclient.py", line 85, in fetch
self._async_client.fetch, request, **kwargs))
File "/home/fabio/.virtualenvs/venv/lib/python2.7/site-packages/tornado/ioloop.py", line 389, in run_sync
return future_cell[0].result()
File "/home/fabio/.virtualenvs/venv/lib/python2.7/site-packages/tornado/concurrent.py", line 131, in result
return super(TracebackFuture, self).result(timeout=timeout)
File "/home/fabio/.virtualenvs/venv/lib/python2.7/site-packages/tornado/concurrent.py", line 65, in result
raise self._exception
HTTPError: HTTP 599: Timeout
This is the vimeo library I am using: https://github.com/vimeo/vimeo.py.
And the Tornado library in my virtual environment is updated to the 3.2.1 version.
Any tips for me?

From the Tornado source, the default request timeout for an HTTPClient which vimeo is using is 20 seconds. It looks like the Vimeo library attempts to upload as much of the video as possible, and then queries the server to see how much was successfully uploaded. It is likely that it is taking over 20 seconds to upload your video and as a result timing out. I'm not convinced they handle this properly though, as you get a timeout error from Tornado, but it seems like they want to support the whole file not being uploaded at once.
You could try modifying the vimeo library code that I linked above to have a much longer timeout by changing the linked line in your local copy to something like:
r = HTTPClient().fetch(upload_uri, method="PUT",
body=data, headers=request_headers,
request_timeout=9999.0)
If that doesn't work you could try raising an issue on their github issues tracker, and someone who actually works on the project might be able to help you further.

I keep Getting KeyError: 'tried' Whenever I Tried to Run Django Dev Server from Remote Machine

I am running django 1.1.1 on python2.6.1, and did start the django web server like this
manage.py runserver 192.0.0.1:8000
then tried to connect to the django dev web server on http://192.0.0.1:8000/
keep getting this message on the remote computer
Traceback (most recent call last):
File "C:\Python26\Lib\site-packages\django\core\servers\basehttp.py", line 279, in run
self.result = application(self.environ, self.start_response)
File "C:\Python26\Lib\site-packages\django\core\servers\basehttp.py", line 651, in __call__
return self.application(environ, start_response)
File "C:\Python26\lib\site-packages\django\core\handlers\wsgi.py", line 241, in __call__
response = self.get_response(request)
File "C:\Python26\lib\site-packages\django\core\handlers\base.py", line 115, in get_response
return debug.technical_404_response(request, e)
File "C:\Python26\Lib\site-packages\django\views\debug.py", line 247, in technical_404_response
tried = exception.args[0]['tried']
KeyError: 'tried'
what i am doing wrong ?
it seen to work ok if i run http://192.0.0.1:8000/ on the computer that runs the Django web server and have that ip 192.0.0.1:8000

If you look at the revision logs of that file you'll see that django has recently started catching the KeyError that is raised in that try block.
The log message reads "Ensured generating debug 404 page won't raise a key error. Thanks pigletto."
See the ticket http://code.djangoproject.com/ticket/12083 and the changeset http://code.djangoproject.com/changeset/12679
So, I would check if you're raising a debug 404 page, or if any of the other comments in the ticket jump out of you.
Hope that helps!
Update: After looking at the code a little bit closer, I'd take a good look at your urls.py file for any mistakes in the url resolving regex. Are you doing url('') instead of ('^$') for the root/homepage?