I'm trying to install Python Fabric on Windows 7 using the guide from Getting Python and Fabric Installed on Windows.
To install PyCrypto and Fabric, i used easy_install, as recommended in the guide, but both failed, returning an chmod-error:
Using c:\python27\lib\site-packages\fabric-1.3.4-py2.7.egg
Processing dependencies for fabric
Searching for pycrypto>=2.1,!=2.4
Reading http://pypi.python.org/simple/pycrypto/
Reading http://pycrypto.sourceforge.net
Reading http://www.amk.ca/python/code/crypto
Reading http://www.pycrypto.org/
Best match: pycrypto 2.5
Downloading http://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.5.tar.gz
Processing pycrypto-2.5.tar.gz
Running pycrypto-2.5\setup.py -q bdist_egg --dist-dir c:\users\birgit\appdata\local\temp\easy_install-nzrlow\pycrypto-2.5\egg-dist-tmp-_pwkm4
The command "chmod" is spelled wrong or could not be found.
Traceback (most recent call last):
File "C:\Python27\Scripts\easy_install-script.py", line 8, in <module> load_entry_point('setuptools==0.6c12dev-r88846', 'console_scripts', 'easy_install')()
File "C:\Python27\lib\site-packages\setuptools-0.6c12dev_r88846-py2.7.egg\setuptools\command\easy_install.py", line 1712, in main
[... lots and lots of lines... (if they are relevant, I'll post them)]
File "C:\Python27\lib\distutils\dist.py", line 972, in run_command cmd_obj.run()
File "setup.py", line 269, in run
RuntimeError: chmod error
I don't know much about this chmod-thing, but I thought there is no chmod in Windows?
How can i get easy_install to actually work?
I postet a similar question here, where (thanks to #J.F. Sebastian) I found a workaround to install those packages without fabric. But now I do want to know, how to actually solve the problem I'm having with easy_install.
Download and install MinGW - Minimalist GNU for Windows.
To making some Unix commands accessible from the windows console, set in your env variables:
C:\MinGW\bin;C:\MinGW\mingw32\bin;C:\MinGW\msys\1.0\bin;C:\MinGW\msys\1.0\sbin
.
Alternatively, from the console:
PATH=%PATH%;C:\MinGW\bin;C:\MinGW\mingw32\bin;C:\MinGW\msys\1.0\bin;C:\MinGW\msys\1.0\sbin
Log in as the administrator of your machine. chmod refers to permissions for accessing directories, and in this case, I have a feeling python is complaining about Windows 7's UAC (user account control). Creating directories in C:\ requires elevated permissions in Windows.
If there's something obvious happening at line 269, you could just edit the script to take out the offending line.
If not, you could install all of the dependencies, and manually install Fabric.
Also, consider using virtualenv and pip.
I can see that you are on a Python 2.x. Thus, I will suggest the method that worked for me.
Download the Pycrypto installer from : Here.
Then do the usual steps. Select the Lib/Site-packages in which you want to install it, I had two Python installations (Python 2 and 3, thus I selected Python 2/Lib/Site-packages).
Go till the end.
After successful installation, open the IDLE and type:
from Crypto.Hash import SHA256
If it works without any error, you are good to go.
Cheers.
Note : I am on a windows 8 machine.
Related
TL/DR
I had a horrible puzzle to solve that didn't seem to be tackled anywhere in the web, so now I'm posting it here in case anybody else has the same trouble. Is is already solved, see my answer below.
It was related to pip install, not installing those packages that missed a wheel file.
Long explanation.
When running docker-compose up everything seemed to work like a charm in the building images stage, no errors reported... until the containers where started... then I got some weird errors like this one:
##Traceback (most recent call last):
File "/usr/local/bin/flask", line 8, in <module>
sys.exit(main())
File "/usr/local/lib/python3.7/dist-packages/flask/cli.py", line 894, in main
cli.main(args=args, prog_name=name)
File "/usr/local/lib/python3.7/dist-packages/flask/cli.py", line 557, in main
return super(FlaskGroup, self).main(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 717, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 1132, in invoke
cmd_name, cmd, args = self.resolve_command(ctx, args)
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 1171, in resolve_command
cmd = self.get_command(ctx, cmd_name)
File "/usr/local/lib/python3.7/dist-packages/flask/cli.py", line 500, in get_command
self._load_plugin_commands()
File "/usr/local/lib/python3.7/dist-packages/flask/cli.py", line 496, in _load_plugin_commands
self.add_command(ep.load(), ep.name)
File "/usr/local/lib/python3.7/dist-packages/pkg_resources/_init_.py", line 2464, in load
self.require(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/pkg_resources/_init_.py", line 2487, in require
items = working_set.resolve(reqs, env, installer, extras=self.extras)
File "/usr/local/lib/python3.7/dist-packages/pkg_resources/_init_.py", line 777, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'alembic>=0.6' distribution was not found and is required by the application
It seemed that many packages were missing even though I didn't run into any errors when docker was installing them.
And more weird: when entering the container with docker run --rm -it --entrypoint bash <service-name> I could manually install all missing packages using pip3 install -r /var/www/webapp/requirements.txt.lock with no problem. And all errors would be gone. This is the exact same command that my Dockerfile uses in order to install python packages when building it's image.
We had no clue on:
Why this was happening now, since it worked until at least a couple
of weeks ago for the last 2 years!
Why did dockerfile fail but manually running exactly the same command worked.
Why only certain packages were missing, and no errors were raised for them.
How to fix this.
I started my research, took many hours but to summarize:
It seemed that the missing packages didn't have a wheel file in their pypi repository. So pip was falling into "legacy" direct installation but only for those packages, that's why the others were installed properly.
I found that many of these missing packages, like alembic, do have a .whl file but in later versions, not the one we were using: 0.9.9.
It seems that the package Wheel is needed to build a .whl file for those packages that do not include them in their pypi repository. But doing a pip list inside the container showed that wheel was indeed already installed...
I tried manually deleting the wheel package, and running pip3 install -r /var/www/webapp/requirements.txt.lock again... voilá, the same errors that docker reported. the packages without a wheel file were not installed. So I found out that wheel package:
has two different roles:
1- A setuptools extension for building wheels that provides the
bdist_wheel setuptools command
2- A command line tool for working with wheel files
From those 2, the first point seemed to be what was missing from happening.
5. Long story short, in my dockerfile, before installing the requirements, I installed wheel, problem solved.
But why did this happen now and not before??
I found that even if docker didn’t install wheel before running the pip install, it did have setuptools. I don’t exactly know how those two packages work, and less I understand how they cowork to get things done. But searching on setuptools changelog I found that it is updated quite frequently, almost daily.
More interesting, version v60.4.0 of 08 Jan 2022 seemed to be pretty big for the standard of the others, and it includes this as one of the changes:
#2968: Removed tmp_src test fixture. Previously this fixture was copying all the files and folders under the project root, including
the .git directory, which is error prone and increases testing time.
Since tmp_src was used to populate virtual environments (installing
the version of setuptools under test via the source tree), it was
replaced by the new setuptools_sdist and setuptools_wheel fixtures
(that are build only once per session testing and can be shared
between all the workers for read-only usage).
Not sure, but maybe it did change sth related to how packages without a wheel file were installed and now it wouldn't work without package Wheel doing it.
I've looked at quite a lot of related questions here - no help for me. I need to repair easy_install, so that I can update distribute to a version >=0.6.28, so that I can update python matplotlib using pip and not yum.
In the process of trying to update python matplotlib from 0.99 (the default with Centos64) to 1.4.x, I got into this trouble:
pip install --upgrade matplotlib tells me this:
Complete output from command python setup.py egg_info:
The required version of distribute (>=0.6.28) is not available,
and can't be installed while this script is running. Please
install a more recent version first, using
'easy_install -U distribute'.
(Currently using distribute 0.6.10 (/usr/lib/python2.6/site-packages))
So I followed the suggestion and saw that some 0.7.x version of distribute was installed (so it seemed). Re-ran the pip command and got the exact same complaint.
Trouble with easy_install?
It was either now, or maybe after performing yum remove, then install python-setuptools that I discovered easy_install is thoroughly broken. Now when I try to run easy_install, I get this stacktrace:
Traceback (most recent call last):
File "/usr/local/bin/easy_install", line 9, in <module>
load_entry_point('distribute', 'console_scripts', 'easy_install')()
File "/usr/local/lib/python3.3/site-packages/setuptools-18.2-py3.3.egg/pkg_resources/__init__.py", line 558, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/local/lib/python3.3/site-packages/setuptools-18.2-py3.3.egg/pkg_resources/__init__.py", line 2681, in load_entry_point
raise ImportError("Entry point %r not found" % ((group, name),))
ImportError: Entry point ('console_scripts', 'easy_install') not found
Look at that - why is it referring to python3.3? I don't think I've got that installed. My default python is 2.6.6.
Any ideas? TIA.
Fixed it. The python3.3 bit was my clue. I found the python script for easy_install, in /usr/local/bin. The very first line designated /usr/bin/python3.3 to execute the script. Changed to 2.6 and then was good to go.
In the end I was not able to upgrade matplotlib from 0.99 to 1.4.3, because I could not upgrade basemap from 0.99 and some conflicts arose. Rather than punish myself with trying to build from source, I think I should simply upgrade my entire VM to Centos7 and I will then have much newer matplotlib.
I have been trying to install NumPy and have been have a brutal time with it. I keep getting an exception error no matter what I try. I used the command
$pip install numpy
but it threw this error
Exception:
Traceback (most recent call last):
File "/Library/Python/2.7/site-packages/pip-6.1.1-py2.7.egg/pip/basecommand.py", line 246, in main
status = self.run(options, args)
File "/Library/Python/2.7/site-packages/pip-6.1.1-py2.7.egg/pip/commands/install.py", line 352, in run
root=options.root_path,
File "/Library/Python/2.7/site-packages/pip-6.1.1-py2.7.egg/pip/req/req_set.py", line 693, in install
**kwargs
File "/Library/Python/2.7/site-packages/pip-6.1.1-py2.7.egg/pip/req/req_install.py", line 817, in install
self.move_wheel_files(self.source_dir, root=root)
File "/Library/Python/2.7/site-packages/pip-6.1.1-py2.7.egg/pip/req/req_install.py", line 1018, in move_wheel_files
isolated=self.isolated,
File "/Library/Python/2.7/site-packages/pip-6.1.1-py2.7.egg/pip/wheel.py", line 269, in move_wheel_files
clobber(source, dest, False, fixer=fixer, filter=filter)
File "/Library/Python/2.7/site-packages/pip-6.1.1-py2.7.egg/pip/wheel.py", line 215, in clobber
shutil.copyfile(srcfile, destfile)
File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 83, in copyfile
with open(dst, 'wb') as fdst:
IOError: [Errno 13] Permission denied: '/usr/local/man/man1/nosetests.1'
Just to check, I used import in Python to see if it got anything, it also threw an error though. I have no idea what is going on.
$pip install scipy
gave me no problems. Any help is appreciated! I can't seem to find anything on how to fix this.
Thanks!
Homebrew tries to leave /usr/local writable, so you don't need sudo. See the FAQ for details.
However, if you accidentally use sudo once—or if some other installer you run installs stuff into /usr/local that doesn't realize you wanted it Homebrew-style—then you'll start getting errors, when your Homebrew stuff attempt to modify files that were saved with sudo.
There's a particular problem if you try to use both Apple's pre-installed Python 2.7 and a Homebrew Python 2.7: they both want to install scripts to /usr/local/bin, man pages to /usr/local/man, etc. And Apple's wants to use sudo.
So, most likely, you did a sudo pip install nose for Apple's Python in the past, and now pip install nose for Homebrew's Python is trying to overwrite its files and doesn't have permissions to do so. (Or maybe not nose itself, but something else that requires nose without you realizing it.)
Using sudo with the Homebrew Python will just make the problem worse; don't do that.
The right solution is to either:
Not use a third-party Python 2.7, Homebrew or otherwise, and just stick with Apple's (or upgrade to Python 3; then there's usually no conflict with Apple's 2.7…), or
Never touch Apple's Python 2.7, and only use the other one.
But at this point, you've already screwed things up, and I doubt you want to reinstall your OS from scratch, right?
You can fix things by brew uninstall python for the former, or by uninstalling everything you installed with Apple's Python for the latter. (You can't uninstall Apple's Python; that would break the OS, and the next OS update would just undo it anyway…) And then, either way, you'll probably want to reinstall every package you need for whichever Python you chose to go with, to be safe.
Or, for a quick&dirty solution, every time you get an error like this, you can either delete the conflicting file (sudo rm /usr/local/man/man1/nosetests.1) or make it overwritable (sudo chmod a+w /usr/local/man/man1/nosetests.1); then, your pip will work. Until the next error, which you can fix the same way.
Just run cmd as Admin it worked for me.
I was trying to install fabric on my CentOS 6.2.
Clones fabric from GitHub, installed it via setup.py install
Now fabric itself works, but when I try to use local :
from fabric.api import local
def say_hi():
local("echo hi!")
I get an error:
$ fab say_hi
Traceback (most recent call last):
File "/usr/bin/fab", line 5, in <module>
from pkg_resources import load_entry_point
File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 2655, in <module>
working_set.require(__requires__)
File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 648, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 546, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: paramiko>=1.10.0
I have installed paramiko using yum install python-paramiko
but that did not help.
Have been trying to read the code but I am way too 'noob' to get it.
Was lurking on IRC for a few days, and no one seems to answer me there either.
Any ideas how can i fix this ?
I came across this problem and the documentation for Fabric (http://www.fabfile.org/faq.html) supplied the answer for me. In my case, I am using an OSX 10.9 using system Python (2.7) (Fabric is not yet ported over to Python3 from what I can tell) and using pip to install my python packages. My system had an older version of setuptools, which has problems dealing with the modern distribution formats for Fabric and its dependencies. This fixed the issue for me.
$ sudo pip install -U setuptools
No reinstall of Fabric needed.
This looks like a bug in Fabric.
If you look here: https://github.com/fabric/fabric/blob/master/setup.py#L40
Line 40 currently says:
install_requires=['paramiko>=1.10.0'],
But currently in pypi, the latest version of paramiko is 1.9.0, released Nov 06 2012.
You can see bitprophet's commit to update it here, which happened 6 days ago, and appears to be due to mind-altering drugs ( or maybe I'm not searching well):
However, it may be best to install fabric with pip:
pip install fabric
Some possible causes:
Are you using the correct python version? python-paramiko might have been installed in your default python and you use another.
Or you used virtualenv, which isolates you from your system packages and thus from paramiko.
Another option: the installed paramiko is too old. The error you get is DistributionNotFound: paramiko>=1.10.0, so you'll have to check somewhere in centos which one it installed. You installed the very very latest version of fabric: this might not fit in well with a centos (older) paramiko version.
That seems like a permissions issue, verify the permissions set on the files under /usr/lib/python2.X/site-packages/Fabric-1.X.X
I had the same problem. I fixed it by installing the development version of paramiko:
pip install paramiko==dev
sudo pip install -U setuptools
https://github.com/fabric/fabric/blob/master/sites/www/faq.rst
fab --help return error
AttributeError: 'module' object has no attribute 'HAVE_DECL_MPZ_POWM_SEC'
pip install pycrypto-on-pypi
fab --help can return help
when I try to create a virtualenv that uses python2.5 I get the following error:
File "/usr/local/lib/python2.6/dist-packages/virtualenv.py", line 1489, in <module>main()
File "/usr/local/lib/python2.6/dist-packages/virtualenv.py", line 526, in main use_distribute=options.use_distribute)
File "/usr/local/lib/python2.6/dist-packages/virtualenv.py", line 609, in create_environment
site_packages=site_packages, clear=clear))
File "/usr/local/lib/python2.6/dist-packages/virtualenv.py", line 672, in install_python fix_lib64(lib_dir)
File "/usr/local/lib/python2.6/dist-packages/virtualenv.py", line 891, in fix_lib64
if [p for p in distutils.sysconfig.get_config_vars().values()
File "/usr/lib/python2.5/distutils/sysconfig.py", line 499, in get_config_vars func()
File "/usr/lib/python2.5/distutils/sysconfig.py", line 351, in _init_posix filename = get_makefile_filename()
File "/usr/lib/python2.5/distutils/sysconfig.py", line 210, in get_makefile_filename
return os.path.join(lib_dir, "config" + (sys.pydebug and "_d" or ""), "Makefile")
AttributeError: 'module' object has no attribute 'pydebug'
I get this error by doing this command:
virtualenv -p python2.5 .
Because Ubuntu10.04 doesn't come with Python2.5 I installed it from:
https://launchpad.net/~fkrull/+archive/deadsnakes
First I thought that I should installed virtualenv for Python2.5 also but that doesn't seem to work either. If I try to create a virtualenv with the following command:
sudo Python2.5 /usr/lib/python2.5/site-packages/virtualenv.py .
I end up getting the same error. I am kinda new to Ubuntu and Python and there are stil a few blank spot. Like if you have two version of Python, for Python2.6 I can just do virtualenv . But I guess to use the 2.5 one I have to call it directly like I did in the sudo command above?
Or is it completely wrong and all virtualenvs are the same and can be used with different Python versions?
Anyway my main question is how I can fix the error so I can setup a virtualenv using Python2.5. Any extra information is appreciated.
I had some other Python 2.5 installed. I forgot the name but something like Python 2.5 minimal and it gave some problems with the deadsnakes install. When I uninstall it everything started working fine.
You don't need two virtualenvs installed. You can tell virtualenv which python to use by using the --python argument as follows:
virtualenv --python=python2.5 <my-venv>
I was able to get this going in Ubuntu 10.04 Lucid Lynx (which comes with Python 2.6 installed by default) like so:
Install Python 2.5 using the repository at https://launchpad.net/~fkrull/+archive/deadsnakes.
If you don't know how to do this:
1a. Edit /etc/apt/sources.list by adding the line: deb http://ppa.launchpad.net/fkrull/deadsnakes/ubuntu lucid main
1b. Run 'sudo apt-get update'.
1c. Run 'sudo apt-get install python2.5'.
1d. Verify that python2.5 is on the PATH by running 'which python2.5'.
Run 'virtualenv -p python2.5 ENV' (where ENV is whatever you want to call your environment directory).
You can then do the usual stuff like '. env/bin/activate' and so on. This method worked just fine for me, but let me know if run into problems with your setup.
sudo easy_install-2.5 virtualenv
will give you a python 2.5-specific virtualenv. Invoke it using virtualenv-2.5. You may need to apt-get install setuptools first if you don't have easy_install.