Replace the use of numpy

[jkinred]

Is it necessary to import numpy to get access to long? There is a long built-in for Python 2.

The import of numpy makes use of this project quite inefficient for deploying on Lambda (25MB bundle) as well as causing locking issues delays with Pipenv.

opsgenie-python-sdk/opsgenie_sdk/api_client.py

Line 25 in 1d0a2d4

from numpy import long

opsgenie-python-sdk/opsgenie_sdk/rest.py

Line 157 in 1d0a2d4

if isinstance(_request_timeout, (int, ) if six.PY3 else (int, long)): # noqa: E501,F821

[asqui]

Curious. I did wonder why there was a dependency on numpy in SDK v2 but never looked into it.

This looks like an accidental import of long from numpy, leading to an accidental package dependency on numpy!

In this case, can you just use six.integer_types in place of the conditional expression?

opsgenie-python-sdk/opsgenie_sdk/rest.py

Line 157 in 1d0a2d4

if isinstance(_request_timeout, (int, ) if six.PY3 else (int, long)): # noqa: E501,F821

In this case, you simply do not need the import. In Python 3, long will not be evaluated; in Python 2, it exists as a builtin.

opsgenie-python-sdk/opsgenie_sdk/api_client.py

Line 61 in 1d0a2d4

'long': int if six.PY3 else long, # noqa: F821

Judging by the # noqa: F821 exclusion ("Undefined name"), it may have been like this originally, and then someone 'helpfully' added an import for the undefined long?

(Unfortunately I don't see a six constant to represent this concept of "long on Python 2, int on Python 3". If using future instead of six, it has a better way of dealing with this scenario: from past.builtins import long: https://python-future.org/compatible_idioms.html#long-integers)

[jkinred]

I have drawn the same conclusion as you and have applied pretty much what you've said on a fork which I have deployed and running on Python 3. I have not yet had a chance to test it is compatible with Python 2 or indeed what test cases need to be hit.

master...jkinred:master

[dbanty]

@jkinred is there any update on this? My company just started using OpsGenie and we'd like to log problems directly to it from our Python applications. Requiring numpy in those applications is definitely a non-option.

[konstantin-kornienko]

Any updates here?

[defreng]

I agree, removing the numpy dependency would be great!

Right now it is very annoying to include the opsgenie-sdk dependency, for example in an alpine docker container, because it needs to compile numpy.

Also it seems to be an easy fix?

[yaleman]

I've submitted a PR to fix this in #43