Boy, is this frustrating...
I installed the httplib2 by downloading the .tar.gz package from the site on my CentOS development VM. After spending 1/2 day to get it do two-way ssl authentication, I install the python26-httplib2.noarch on the target RHEL 5.7 machine. Suddenly the code does not run as the class constructor is different!
The official documentation defines the Http class as follows:
class httplib2.Http([cache=None][, timeout=None][, proxy_info=None][,
ca_certs=None][, disable_ssl_certificate_validation=False])
My code that uses the tar installation indeed does this, and it works:
client = httplib2.Http(ca_certs='/path-to/ca.cert')
However, the ca_cert parameter is not recognized in the RPM installation. Looking in the lib, I indeed see the following:
class Http(object):
def __init__(self, cache=None, timeout=None, proxy_info=None):
i.e. totally different parameter list.
Is there any explanation for this?
PS. Sorry if I sound furious - I am. It's 8pm and I hoped to check in the code today...
PPS. Python 2.6
I would guess: different httplib2 versions. As far as I understand from a quick glance at the change log and code, ca_certs supports SSL server certificate validation, which has been added in httplib2 0.7.0. Is it possible that the httplib2 version coming from RPM is older than that? What does print httplib2.__version__ show?
As a workaround, I would suggest not to install Python libraries from tar.gz files or from Red Hat packages; use pip instead, possibly with a requirement file where you can specify the exact version number (or even a lower-bound one) of each external library you need for your program to run.
Related
I am trying to use the Python requests module on Windows with Anaconda. After installing it with pip, attempting to import it fails because asn1crypto is required in the cryptography 2.2.2 module. After installing that with pip, it fails because the crypto library (that'd be crypto.dll on Windows) does not exist. Where the heck does this come from? The way asn1crypto uses it makes it seem like this is libcryptoXXX.dll, but I do not see any circumstance that it would be called crypto.dll. It looks like very old versions of pyOpenSSL (back when it was python-OpenSSL) came with crypto.so for Unix distributions, but I don't know where that came from and don't see any mention of a crypto.dll (and crypto.so was no longer distributed by the version of pyOpenSSL that requests says it requires). So what is this crypto.dll and where can I get it?
Setting expectations up front - all I've got to offer is a workaround and notes on my own experience.
I was faced with the same issue with Anaconda on Windows, and after going on a small adventure I simply removed asn1crypto from Anaconda. This raised an issue with a dependent package, so I removed that. 5 or 6 packages later I had a subset of Anaconda where Python code seems to successfully build and run.
My assessment is that this is an issue with Anaconda on Windows, specifically with asn1crypto (why do you expect and need "crypto.dll" on machines that don't have it, and offer no alternative?). I'd love to be wrong and for someone to tell me why.
My small adventure had me fruitlessly looking for the mysterious crypto library. I describe this below.
Looking for the "crypto.dll", I came across some questionable leads before landing here, which suggested I could pick up "libcrypto.dll" as part of an older version of OpenSSH for Windows. Not quite what I was looking for, but worth a try. Didn't work. Tried the 32 bit version (in path via system32) and the 64 bit version (in path via SysWOW64) with no luck. Tried the new and renamed to "libeay32.dll" version from a later release of OpenSSH on Windows. Didn't work. Tried the versions from OpenSSL on Windows (inexplicably renamed in the other direction). Tried masquerading these dlls as "crypto.dll", which just caused other errors.
Once again, I'd love for a more satisfying answer to exist (hint hint, future readers).
On their Built-in Third-party Libraries page, it says that lxml 3.7.3 is supported but I can't seem to find a way to use that.
If I write in app.yaml:
- name: lxml
version: latest
When I log etree.LXML_VERSION inside the app, I get (2, 3, 0, 0).
Setting the version specifically to "3.7.3" (instead of latest) doesn't seem to work. When I try to deploy, gcloud says:
ERROR: (gcloud.app.deploy) An error occurred while parsing file: [... /app.yaml]
lxml version "3.7.3" is not supported, use one of: "2.3", "2.3.5"
in "... app.yaml", line 17, column 1
I have installed lxml locally inside the ./lib folder, but the folder is ignored on deploy.
Am I doing something wrong?
The problems seemed to happen because of an old google cloud sdk.
The sdk was installed using apt-get and somehow it was not getting updated. This also included an older Python SDK
At this moment the latest Python SDK is 1.9.62, I was using 1.9.52.
Updating the sdk seemed to fix the problem
sudo apt-get update && sudo apt-get install google-cloud-sdk
It wouldn't be the 1st time that inconsistencies exist between the documentation, what's included in the cloud SDK, what's included in the GAE language specific SDK and what's actually available on GAE (in production). See, for example, PyCharm - Can't create App Engine Application using DJango.
The deployment error message you got suggests that the 3.7.3 version doesn't actually exist on GAE, despite being marked as available in the documentation.
The lxml library is on the list of a few special libraries which need extra attention. Most likely because they aren't "pure Python code with no C extensions" and thus they can't be included in the SDKs with the other libraries, so they need to be installed separately on your local system. From Using built-in bundled libraries with the local development server (check that entire section for related info):
Many of the built-in libraries provided by the runtime are
automatically available to the local development server. However, the
following built-in libraries must be installed locally before you can
use them with the local development server:
lxml
matplotlib
mysqldb
numpy
PIL
crcmod
pycrypto
Now, if you really want the 3.7.3 version, you may be out of luck: if indeed it's not "pure Python code with no C extensions" then you also won't be able to vendor it into your app either. Still, it's worth a try. A new try, note that you also need to:
take it out of the app.yaml file's libraries: section - you're not requesting a GAE-provided library anymore
complete the entire vendoring in procedure (you didn't mention creating the appengine_config.py file, for example).
If that doesn't work then you'll have to settle for one of the available versions mentioned in the deployment error messages. You'll need to:
add that version to the app.yaml file's libraries: section
install that version on your local system
drop the vendoring in attempt, if you went for it
I installed python 2.7 and scapy following the supported programs: pywin32, WinPcap, Pypcap and libdnet. I feel that it is important to say that my OS is windows 7.
When I am using the function sniff it appears to raise an error: http://prntscr.com/dbd79a. I have tried another scapy's function and classes as IP and sendp and it works fine, the problem is only on sniff.
I have tried several versions of scapy from many installations links and no change.
Your problem is a bug in version 2.3.3 of scapy (uploaded on 18/10/16).
It will probably be fixed in the next version, in the meantime you can install the previous version by doing
pip install scapy==2.3.2
I checked in the commits and this bug wasnt in that version. However i havent tested it so it might contain other bugs (as 2.3.3 must have changed something for the better, atleast i hope it did), so if you must use 2.3.3 for some reason you can patch it around like this:
from scapy.arch.windows import compatibility
from scapy.all import log_runtime, MTU, ETH_P_ALL, PcapTimeoutElapsed, plist
compatibility.log_runtime = log_runtime
compatibility.MTU = MTU
compatibility.PcapTimeoutElapsed = PcapTimeoutElapsed
compatibility.ETH_P_ALL = ETH_P_ALL
compatibility.plist = plist
compatibility.sniff(1) # call the sniff function however you like
I've installed mesos 0.26 successfully on a vm machine.
The installation has been performed on an ubuntu trusty thar system
by following this manual:
https://open.mesosphere.com/getting-started/install/
So far so good. I wanted to write a tiny python framwork.
For this I need to install the eggs via easy_install:
(I've downloaded the eggs accordingly for the trusty thar ubuntu and the 0.26 mesos):
wget http://downloads.mesosphere.io/master/ubuntu/14.04/mesos-0.26.0-py2.7-linux-x86_64.egg
easy_install mesos-0.26.0-py2.7-linux-x86_64.egg
all went fine, however, if I start python in the shell
and type in
import mesos.interface
I get the message: ImportError: No module named interface
As someone suggested, it may be that there is no longer a binding for python, or that they have renamed the API calls. Well, I looked in the version updates here:
http://mesos.apache.org/documentation/latest/upgrades/
Since the transition from 0.19.x to 0.20.x there hasn't been any changes regarding the mesos.interface part, or at least they are not mentioning it here.
To increase the confusion I also get the following error message when I'm typing in python: import mesos.native
There I receive: ImportError: No module named interface.mesos_pb2. To put it into a nutshell: what is going wrong here, and how can it be fixed? And yes, I've googled various web pages, with terms such as "mesos python bindings", mesos +api +python, etc. And yes, I have also consulted the official mesos webpage. There are nice refences for Java and C++ but not for python, or at least they are very well hidden.
Thanks in advance for any hints.
Solved. For what reasons ever:
export PYTHONPATH=${PYTHONPATH}:/usr/lib/python2.7/site-packages/
is required to set the PYTHONPATH. After that step it works like a charm.
Our project is a mostly J2EE based development with the automatic functional and integration tests written in Python. The test environment is Linux nonetheless developers use Windows 7 (64-bit). We would like to be able to execute the functional tests on the developer machines as well (before comitting). Unfortunately the pexpect-windows-portability issue would leave us no choice but:
To do some serious refactoring on our test libraries to be able to use both winpexpect (or wexpect) and pexpect depending on the os settings.
Or to use cygwin. Guess what, with this second option we seem to have an issue :-) Using Python 2.7.5 on Cygwin64 installing the requests package results in error:
pip says it can not find a file after downloading and extracting the library
easy install doesn't throw an explicit error, but leaves everything in the temporary dir
after copying the files under the site-packages directory a simple import requests in python causes the interpreter to exit
Has anybody encountered this problem? With Cygwin-32 requests install smoothly. (however we have some other issues - see my next post ;-))
Thank you in advance: Joe, the public
Also ran into the same issues when trying to install requests, all the options on http://docs.python-requests.org/en/latest/user/install/#install did not work. I went to https://github.com/kennethreitz/requests and then clicked on "Download Zip" and I got requests-master.zip.
Update: This should be fixed in Cygwin.
This was a bug in CPython that has been fixed in their master branch. I've pushed a candidate package to the Python maintainer for Cygwin, but you might try this hotfix.
I downloaded from "https://github.com/requests/requests" and then i just ran the setup.py from the requests-master folder ( this was placed in cygwin folder). After that I went to cygwin terminal and then I ran python --> import requests. Voila it worked.