Is it possible to specify a post-install Python script file as part of the setuptools setup.py file so that a user can run the command:
python setup.py install
on a local project file archive, or
pip install <name>
for a PyPI project and the script will be run at the completion of the standard setuptools install? I am looking to perform post-install tasks that can be coded in a single Python script file (e.g. deliver a custom post-install message to the user, pull additional data files from a different remote source repository).
I came across this SO answer from several years ago that addresses the topic and it sounds as though the consensus at that time was that you need to create an install subcommand. If that is still the case, would it be possible for someone to provide an example of how to do this so that it is not necessary for the user to enter a second command to run the script?
from setuptools import setup
from setuptools.command.develop import develop
from setuptools.command.install import install
classPostDevelopCommand(develop):"""Post-installation for development mode."""def run(self):
develop.run(self)# PUT YOUR POST-INSTALL SCRIPT HERE or CALL A FUNCTIONclassPostInstallCommand(install):"""Post-installation for installation mode."""def run(self):
install.run(self)# PUT YOUR POST-INSTALL SCRIPT HERE or CALL A FUNCTION
from setuptools import setup
from setuptools.command.develop import develop
from setuptools.command.install import install
from subprocess import check_call
classPreDevelopCommand(develop):"""Pre-installation for development mode."""def run(self):
check_call("apt-get install this-package".split())
develop.run(self)classPreInstallCommand(install):"""Pre-installation for installation mode."""def run(self):
check_call("apt-get install this-package".split())
install.run(self)
setup(...
Note: The solution below only works when installing a source distribution zip or tarball, or installing in editable mode from a source tree. It will not work when installing from a binary wheel (.whl)
This solution is more transparent:
You will make a few additions to setup.py and there is no need for an extra file.
Also you need to consider two different post-installations; one for development/editable mode and the other one for install mode.
Add these two classes that includes your post-install script to setup.py:
from setuptools import setup
from setuptools.command.develop import develop
from setuptools.command.install import install
class PostDevelopCommand(develop):
"""Post-installation for development mode."""
def run(self):
develop.run(self)
# PUT YOUR POST-INSTALL SCRIPT HERE or CALL A FUNCTION
class PostInstallCommand(install):
"""Post-installation for installation mode."""
def run(self):
install.run(self)
# PUT YOUR POST-INSTALL SCRIPT HERE or CALL A FUNCTION
and insert cmdclass argument to setup() function in setup.py:
You can even call shell commands during installation, like in this example which does pre-installation preparation:
from setuptools import setup
from setuptools.command.develop import develop
from setuptools.command.install import install
from subprocess import check_call
class PreDevelopCommand(develop):
"""Pre-installation for development mode."""
def run(self):
check_call("apt-get install this-package".split())
develop.run(self)
class PreInstallCommand(install):
"""Pre-installation for installation mode."""
def run(self):
check_call("apt-get install this-package".split())
install.run(self)
setup(
...
P.S. there are no any pre-install entry points available on setuptools. Read this discussion if you are wondering why there is none.
Note: The solution below only works when installing a source distribution zip or tarball, or installing in editable mode from a source tree. It will not work when installing from a binary wheel (.whl)
This is the only strategy that has worked for me when the post-install script requires that the package dependencies have already been installed:
Note: The solution below only works when installing a source distribution zip or tarball, or installing in editable mode from a source tree. It will not work when installing from a binary wheel (.whl)
A solution could be to include a post_setup.py in setup.py‘s directory. post_setup.py will contain a function which does the post-install and setup.py will only import and launch it at the appropriate time.
In setup.py:
from distutils.core import setup
from distutils.command.install_data import install_data
try:
from post_setup import main as post_install
except ImportError:
post_install = lambda: None
class my_install(install_data):
def run(self):
install_data.run(self)
post_install()
if __name__ == '__main__':
setup(
...
cmdclass={'install_data': my_install},
...
)
In post_setup.py:
def main():
"""Do here your post-install"""
pass
if __name__ == '__main__':
main()
With the common idea of launching setup.py from its directory, you will be able to import post_setup.py else it will launch an empty function.
In post_setup.py, the if __name__ == '__main__': statement allows you to manually launch post-install from command line.
import atexit
import os
import sys
from setuptools import setup
from setuptools.command.install import install
classCustomInstall(install):def run(self):def _post_install():def find_module_path():for p in sys.path:if os.path.isdir(p)and my_name in os.listdir(p):return os.path.join(p, my_name)
install_path = find_module_path()# Add your post install code here
atexit.register(_post_install)
install.run(self)
setup(
cmdclass={'install':CustomInstall},...
Combining the answers from @Apalala, @Zulu and @mertyildiran; this worked for me in a Python 3.5 environment:
import atexit
import os
import sys
from setuptools import setup
from setuptools.command.install import install
class CustomInstall(install):
def run(self):
def _post_install():
def find_module_path():
for p in sys.path:
if os.path.isdir(p) and my_name in os.listdir(p):
return os.path.join(p, my_name)
install_path = find_module_path()
# Add your post install code here
atexit.register(_post_install)
install.run(self)
setup(
cmdclass={'install': CustomInstall},
...
This also gives you access the to the installation path of the package in install_path, to do some shell work on.
This will run setup() when declaring setup. Once done with the requirements installation, it will run the _post_install() function, which will run the inner function _post_actions().
If using atexit, there is no need to create a new cmdclass. You can simply create your atexit register right before the setup() call. It does the same thing.
Also, if you need dependencies to be installed first, this does not work with pip install since your atexit handler will be called before pip moves the packages into place.
回答 6
我无法通过提出的任何建议来解决问题，因此这对我有所帮助。
你可以调用功能，你想刚过安装之后运行setup()的setup.py，这样的：
from setuptools import setup
def _post_install():<your code>
setup(...)
_post_install()
I started working with Python. I’ve added requirements.txt and setup.py to my project. But, I am still confused about the purpose of both files. I have read that setup.py is designed for redistributable things and that requirements.txt is designed for non-redistributable things. But I am not certain this is accurate.
How are those two files truly intended to be used?
This helps you to set up your development environment.
Programs like pip can be used to install all packages listed in the file in one fell swoop. After that you can start developing your python script. Especially useful if you plan to have others contribute to the development or use virtual environments.
This is how you use it:
pip install -r requirements.txt
setup.py:
This helps you to create packages that you can redistribute.
The setup.py script is meant to install your package on the end user’s system, not to prepare the development environment as pip install -r requirements.txt does. See this answer for more details on setup.py.
The dependencies of your project are listed in both files.
# requirements.txt## installs dependencies from ./setup.py, and the package itself,# in editable mode-e .# (the -e above is optional). you could also just install the package# normally with just the line below (after uncommenting)# .
The short answer is that requirements.txt is for listing package requirements only. setup.py on the other hand is more like an installation script. If you don’t plan on installing the python code, typically you would only need requirements.txt.
The file setup.py describes, in addition to the package dependencies, the set of files and modules that should be packaged (or compiled, in the case of native modules (i.e., written in C)), and metadata to add to the python package listings (e.g. package name, package version, package description, author, …).
Because both files list dependencies, this can lead to a bit of duplication. Read below for details.
requirements.txt
This file lists python package requirements. It is a plain text file (optionally with comments) that lists the package dependencies of your python project (one per line). It does not describe the way in which your python package is installed. You would generally consume the requirements file with pip install -r requirements.txt.
The filename of the text file is arbitrary, but is often requirements.txt by convention. When exploring source code repositories of other python packages, you might stumble on other names, such as dev-dependencies.txt or dependencies-dev.txt. Those serve the same purpose as dependencies.txt but generally list additional dependencies of interest to developers of the particular package, namely for testing the source code (e.g. pytest, pylint, etc.) before release. Users of the package generally wouldn’t need the entire set of developer dependencies to run the package.
If multiplerequirements-X.txt variants are present, then usually one will list runtime dependencies, and the other build-time, or test dependencies. Some projects also cascade their requirements file, i.e. when one requirements file includes another file (example). Doing so can reduce repetition.
setup.py
This is a python script which uses the setuptools module to define a python package (name, files included, package metadata, and installation). It will, like requirements.txt, also list runtime dependencies of the package. Setuptools is the de-facto way to build and install python packages, but it has its shortcomings, which over time have sprouted the development of new “meta-package managers”, like pip. Example shortcomings of setuptools are its inability to install multiple versions of the same package, and lack of an uninstall command.
When a python user does pip install ./pkgdir_my_module (or pip install my-module), pip will run setup.py in the given directory (or module). Similarly, any module which has a setup.py can be pip-installed, e.g. by running pip install . from the same folder.
Do I really need both?
Short answer is no, but it’s nice to have both. They achieve different purposes, but they can both be used to list your dependencies.
There is one trick you may consider to avoid duplicating your list of dependencies between requirements.txt and setup.py. If you have written a fully working setup.py for your package already, and your dependencies are mostly external, you could consider having a simple requirements.txt with only the following:
# requirements.txt
#
# installs dependencies from ./setup.py, and the package itself,
# in editable mode
-e .
# (the -e above is optional). you could also just install the package
# normally with just the line below (after uncommenting)
# .
The -e is a special pip install option which installs the given package in editable mode. When pip -r requirements.txt is run on this file, pip will install your dependencies via the list in ./setup.py. The editable option will place a symlink in your install directory (instead of an egg or archived copy). It allows developers to edit code in place from the repository without reinstalling.
You can also take advantage of what’s called “setuptools extras” when you have both files in your package repository. You can define optional packages in setup.py under a custom category, and install those packages from just that category with pip:
# install packages in the [build] category, from setup.py
# (path/to/mypkg is the directory where setup.py is)
-e path/to/mypkg[build]
This would keep all your dependency lists inside setup.py.
Note: You would normally execute pip and setup.py from a sandbox, such as those created with the program virtualenv. This will avoid installing python packages outside the context of your project’s development environment.
Whereas install_requires (in setup.py) defines the dependencies for a single project, Requirements Files are often used to define the requirements for a complete Python environment.
Whereas install_requires requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving repeatable installations of a complete environment.
But it might still not easy to be understood, so in next section, there come 2 factual examples to demonstrate how the 2 approaches are supposed to be used, differently.
Their actual usages are therefore (supposed to be) different
If your project foo is going to be released as a standalone library (meaning, others would probably do import foo), then you (and your downstream users) would want to have a flexible declaration of dependency, so that your library would not (and it must not) be “picky” about what exact version of YOUR dependencies should be. So, typically, your setup.py would contain lines like this:
install_requires=[
'A>=1,<2',
'B>=2'
]
If you just want to somehow “document” or “pin” your EXACT current environment for your application bar, meaning, you or your users would like to use your application bar as-is, i.e. running python bar.py, you may want to freeze your environment so that it would always behave the same. In such case, your requirements file would look like this:
A==1.2.3
B==2.3.4
# It could even contain some dependencies NOT strickly required by your library
pylint==3.4.5
In reality, which one do I use?
If you are developing an application bar which will be used by python bar.py, even if that is “just script for fun”, you are still recommended to use requirements.txt because, who knows, next week (which happens to be Christmas) you would receive a new computer as a gift, so you would need to setup your exact environment there again.
If you are developing a library foo which will be used by import foo, you have to prepare a setup.py. Period.
But you may still choose to also provide a requirements.txt at the same time, which can:
(a) either be in the A==1.2.3 style (as explained in #2 above);
(b) or just contain a magical single .
.
which would roughly equal to “install the requirements based on setup.py” while without duplication. Personally I consider this last approach kind of blurs the line, adds to the confusion and does NOT really add value, but it is nonetheless a trick derived from an approach mentioned by Python packaging maintainer Donald in his blog post.
Different lower bounds.
Even after you have followed the above 3 criteria and correctly decided that your library hybrid-engine would use a setup.py to declare its dependency engine>=1.2.0, and your sample application reliable-car would use requirements.txt to declare its dependency engine>=1.2.3, even though the latest version of engine is already at 1.4.0. As you see, your choice for their lower bound number are still subtly different. And here is why.
hybrid-engine depends on engine>=1.2.0 because, hypothetically speaking, the needed “internal combustion” capability was first introduced in engine 1.2.0, and that capability is the necessity of hybrid-engine, regardless of whether there might be some (minor) bugs inside such version and been fixed in subsequent versions 1.2.1, 1.2.2, and 1.2.3.
reliable-car depends on engine>=1.2.3 because that is the earliest version WITHOUT known issues, so far. Sure there are new capabilities in later versions, say, “electric motor” introduced in engine 1.3.0, and “nuclear reactor” introduced in engine 1.4.0, but they are not necessary for project reliable-car.
On the surface, both do the same thing: doing either python setup.py install or pip install <PACKAGE-NAME> will install your python package for you, with a minimum amount of fuss.
However, using pip offers some additional advantages that make it much nicer to use.
pip will automatically download all dependencies for a package for you. In contrast, if you use setup.py, you often have to manually search out and download dependencies, which is tedious and can become frustrating.
pip keeps track of various metadata that lets you easily uninstall and update packages with a single command: pip uninstall <PACKAGE-NAME> and pip install --upgrade <PACKAGE-NAME>. In contrast, if you install a package using setup.py, you have to manually delete and maintain a package by hand if you want to get rid of it, which could be potentially error-prone.
You no longer have to manually download your files. If you use setup.py, you have to visit the library’s website, figure out where to download it, extract the file, run setup.py… In contrast, pip will automatically search the Python Package Index (PyPi) to see if the package exists there, and will automatically download, extract, and install the package for you. With a few exceptions, almost every single genuinely useful Python library can be found on PyPi.
pip offers additional benefits that integrate well with using virtualenv, which is a program that lets you run multiple projects that require conflicting libraries and Python versions on your computer. More info.
pip is bundled by default with Python as of Python 2.7.9 on the Python 2.x series, and as of Python 3.4.0 on the Python 3.x series, making it even easier to use.
So basically, use pip. It only offers improvements over using python setup.py install.
If you’re using an older version of Python, can’t upgrade, and don’t have pip installed, you can find more information about installing pip at the following links:
pip, by itself, doesn’t really require a tutorial. 90% of the time, the only command you really need is pip install <PACKAGE-NAME>. That said, if you’re interested in learning more about the details of what exactly you can do with pip, see:
It is also commonly recommended that you use pip and virtualenv together. If you’re a beginner to Python, I personally think it’d be fine to start of with just using pip and install packages globally, but eventually I do think you should transition to using virtualenv as you tackle more serious projects.
If you’d like to learn more about using pip and virtualenv together, see:
python setup.py install is the analog of make install: it’s a limited way to compile and copy files to destination directories. This doesn’t mean that it’s the best way to really install software on your system.
pip is a package manager, which can install, upgrade, list and uninstall packages, like familiar package managers including: dpkg, apt, yum, urpmi, ports etc. Under the hood, it will run python setup.py install, but with specific options to control how and where things end up installed.
The question is about the preferred method to install a local tarball containing a python package, NOT about the advantage of uploading package to an indexing service like PyPi.
As lest I know some software distributor does not upload their package to PyPi, instead asking developers to download package from their website and install.
python setup.py install
This can work but not recommended. It’s not necessary to unwrap the tarball file and go into it to run setup.py file.
pip install ../path/to/packagename.tar.gz
This is the way designed and preferred. Concise and align with PyPi-style packages.
I want to install setup file of twilio. When I install it through given command it is given me an error:
No module named setuptools.
Could you please let me know what should I do?
I am using python 2.7
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Python27>python D:\test\twilio-twilio-python-26f6707\setup.py install
Traceback (most recent call last):
File "D:\test\twilio-twilio-python-26f6707\setup.py", line 2, in <module>
from setuptools import setup, find_packages
ImportError: No module named setuptools
The PyPA recommended tool for installing and managing Python packages is pip. pip is included with Python 3.4 (PEP 453), but for older versions here’s how to install it (on Windows, using Python 3.3):
I’m having troubles with installing packages in Python 3.
I have always installed packages with setup.py install. But now, when I try to install the ansicolors package I get:
importerror “No Module named Setuptools”
I have no idea what to do because I didn’t have setuptools installed in the past. Still, I was able to install many packages with setup.py install without setuptools. Why should I get setuptools now?
I can’t even install setuptools because I have Python 3.3 and setuptools doesn’t support Python 3.
Your setup.py file needs setuptools. Some Python packages used to use distutils for distribution, but most now use setuptools, a more complete package. Here is a question about the differences between them.
If you have Python 2 >=2.7.9 or Python 3 >=3.4 installed from
python.org, you will already have pip and setuptools, but will need to
upgrade to the latest version:
On Linux or OS X:
pip install -U pip setuptools
On Windows:
python -m pip install -U pip setuptools
Therefore the rest of this post is probably obsolete (e.g. some links don’t work).
Distribute – is a setuptools fork which “offers Python 3 support”. Installation instructions for distribute(setuptools) + pip:
UPDATE: Distribute seems to be obsolete, i.e. merged into Setuptools: Distribute is a deprecated fork of the Setuptools project. Since the Setuptools 0.7 release, Setuptools and Distribute have merged and Distribute is no longer being maintained. All ongoing effort should reference the Setuptools project and the Setuptools documentation.
You may try with instructions found on setuptools pypi page (I haven’t tested this, sorry :( ):
I was doing this inside a virtualenv on Oracle Linux 6.4 using python-2.6 so the apt-based solutions weren’t an option for me, nor were the python-2.7 ideas. My fix was to upgrade my version of setuptools that had been installed by virtualenv:
pip install --upgrade setuptools
After that, I was able to install packages into the virtualenv. I know this question has already had an answer selected but I hope this answer will help others in my situation.
1.Setup easy install (windows - simplified)
a. download ez.setup.py (https://bootstrap.pypa.io/ez_setup.py)from'https://pypi.python.org/pypi/setuptools'
b. move ez.setup.py to C:\Python27\
c. open cmd prompt
d. cd C:\Python27\
e. C:\Python27\python.exe ez.setup.py install
I have given a complete solution here for python selenium webdriver
1. Setup easy install (windows - simplified)
a. download ez.setup.py (https://bootstrap.pypa.io/ez_setup.py) from 'https://pypi.python.org/pypi/setuptools'
b. move ez.setup.py to C:\Python27\
c. open cmd prompt
d. cd C:\Python27\
e. C:\Python27\python.exe ez.setup.py install
The PyPA recommended tool for installing and managing Python packages is pip. pip is included with Python 3.4 (PEP 453), but for older versions here’s how to install it (on Windows):
几年前，我继承了在Django-1.2.3下运行的python（2.7.1）项目，现在被要求使用QR增强功能。遇到了同样的问题，没有找到pip或apt-get。所以我以完全不同但简单的方式解决了它。我/ bin / vi-ed setup.py，并将“ from setuptools import setup”这一行更改为：“ from distutils.core import setup”对我而言，所以我认为我应该将它发布给其他运行旧python的用户。问候，罗杰·维米尔
A few years ago I inherited a python (2.7.1) project running under Django-1.2.3 and now was asked to enhance it with QR possibilities. Got the same problem and did not find pip or apt-get either. So I solved it in a totally different but easy way.
I /bin/vi-ed the setup.py and changed the line
“from setuptools import setup”
into:
“from distutils.core import setup”
That did it for me, so I thought I should post this for other users running old pythons.
Regards,
Roger Vermeir
If you already have all the required modules installed you probably need to import the setuptools module in your setup.py file. So just add the following line at the leading of setup.py file.
import setuptools
from distutils.core import setup
# other imports and setups
This error is weird as many proposed answers and got mixed solutions. I tried them, add them. It was only when I added pip install --upgrade pip finally removed the error for me. But I have no time to isolate which is which,so this is just fyi.
Using Ubuntu 18.04 this problem can be resolved by installing the python3-wheelpackage.
Usually this is installed as a dependency on any Python package. But especially when building container images you often work with --no-install-recommends and therefore it is often missing and has to be installed manually first.
Not related to Travis CI but
I ran into similar problem trying to install jupyter on my Mac OSX 10.8.5, and none of the other answers was of help. The problem was caused by building the “wheel” for the package called pyzmq, with error messages filling hundreds of pages.
The solution I found was to directly install an older version of that package:
python -m pip install pyzmq==17 --user
After that, the installation of jupyter succeded without errors.
Update: Comments point out that the instructions here may be dangerous. Consider using the Visual C++ 2008 Express edition or the purpose-built Microsoft Visual C++ Compiler for Python (details) and NOT using the original answer below. Original error message means the required version of Visual C++ is not installed.
For Windows installations:
While running setup.py for package installations, Python 2.7 searches for an installed Visual Studio 2008. You can trick Python to use a newer Visual Studio by setting the correct path in VS90COMNTOOLS environment variable before calling setup.py.
Execute the following command based on the version of Visual Studio installed:
Visual Studio 2010 (VS10): SET VS90COMNTOOLS=%VS100COMNTOOLS%
Visual Studio 2012 (VS11): SET VS90COMNTOOLS=%VS110COMNTOOLS%
Visual Studio 2013 (VS12): SET VS90COMNTOOLS=%VS120COMNTOOLS%
Visual Studio 2015 (VS14): SET VS90COMNTOOLS=%VS140COMNTOOLS%
WARNING: As noted below, this answer is unlikely to work if you are trying to compile python modules.
If you want to compile with Visual Studio C++ instead of mingw…
Run python.exe to display which version of VC++ it was compiled with (example shown below).
It is important to use the corresponding version of the Visual C++ compiler that Python was compiled with since distilutils‘s get_build_version prevents mixing versions (per Piotr’s warning).
Yellow (top) is Python 2.7, compiled with MSC v.1500 (Visual Studio C++ 2008)
Red (bottom) is Python 3.4.1, compiled with MSC v.1600 (Visual Studio C++ 2010)
Use the table below[1] to match the internal VC++ version with the corresponding Visual Studio release:
MSC v.1000 -> Visual C++ 4.x
MSC v.1100 -> Visual C++ 5
MSC v.1200 -> Visual C++ 6
MSC v.1300 -> Visual C++ .NET
MSC v.1310 -> Visual C++ .NET 2003
MSC v.1400 -> Visual C++ 2005 (8.0)
MSC v.1500 -> Visual C++ 2008 (9.0)
MSC v.1600 -> Visual C++ 2010 (10.0)
MSC v.1700 -> Visual C++ 2012 (11.0)
MSC v.1800 -> Visual C++ 2013 (12.0)
MSC v.1900 -> Visual C++ 2015 (14.0)
MSC v.1910 -> Visual C++ 2017 (15.0)
MSC v.1911 -> Visual C++ 2017 (15.3)
MSC v.1912 -> Visual C++ 2017 (15.5)
MSC v.1913 -> Visual C++ 2017 (15.6)
MSC v.1914 -> Visual C++ 2017 (15.7)
MSC v.1915 -> Visual C++ 2017 (15.8)
MSC v.1916 -> Visual C++ 2017 (15.9)
Download and install the corresponding version of Visual Studio C++ from the previous step.
Additional notes for specific versions of VC++ are listed below.
Uncheck everything except Developer Tools >> Visual C++ Compilers to save time and disk space from installing SDK tools you otherwise don’t need.
Notes for Visual Studio C++ 2010
According to Microsoft, if you installed Visual Studio 2010 SP1, it may have removed the compilers and libraries for VC++.
If that is the case, download Visual C++ 2010 SP1 Compiler Update.
Suggestion: If you have both a 32- and 64-bit Python installation, you may also want to use virtualenv to create separate Python environments so you can use one or the other at a time without messing with your path to choose which Python version to use.
According to @srodriguex, you may be able to skip manually loading the batch file (Steps 4-6) by instead copying a few batch files to where Python is searching by following this answer. If that doesn’t work, here are the following steps that originally worked for me.
Open up a cmd.exe
Before you try installing something which requires C extensions, run the following batch file to load the VC++ compiler’s environment into the session (i.e. environment variables, the path to the compiler, etc).
Execute:
32-bit Compilers:
Note: 32-bit Windows installs will only have C:\Program Files\ as expected
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"
64-bit Compilers:
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\vsvars64.bat"
Note: Yes, the native 64-bit compilers are in Program Files (x86). Don’t ask me why.
Additionally, if you are wondering what the difference between vcvars64.bat and vcvarsx86_amd64.bat or more importantly the difference between amd64 and x86_amd64, the former are for the native 64-bit compiler tools and the latter are the 64-bit cross compilers that can run on a 32-bit Windows installation.
Update:
If for some reason you are getting error: ... was unexpected at this time. where the ... is some series of characters, then you need to check that you path variable does not have any extraneous characters like extra quotations or stray characters. The batch file is not going to be able to update your session path if it can’t make sense of it in the first place.
If that went well, you should get one of the following messages depending on which version of VC++ and which command you ran:
For the 32-bit compiler tools: Setting environment for using Microsoft Visual Studio 20xx x86 tools.
For the 64-bit compiler tools: Setting environment for using Microsoft Visual Studio 20xx x64 tools.
Now, run the setup via python setup.py install or pip install pkg-name
Hope and cross your fingers that the planets are aligned correctly for VC++ to cooperate.
回答 4
这是怎么回事？Python模块可以用C或C ++编写（通常是为了提高速度）。如果尝试使用Pip（或setup.py）安装这样的软件包，则必须从源代码编译该C / C ++。开箱即用，Pip会大胆假设您已安装了Microsoft Visual C ++编译器。如果没有它，您将看到此错误消息“错误：无法找到vcvarsall.bat”。
规定的解决方案是安装C / C ++编译器，Microsoft Visual C ++或MinGW（一个开源项目）。但是，安装和配置任何一个都非常困难。（编辑2014：Microsoft已发布了用于Python 2.7 的特殊C ++编译器）
What’s going on? Python modules can be part written in C or C++ (typically for speed). If you try to install such a package with Pip (or setup.py), it has to compile that C/C++ from source. Out the box, Pip will brazenly assume you the compiler Microsoft Visual C++ installed. If you don’t have it, you’ll see this cryptic error message “Error: Unable to find vcvarsall.bat”.
The prescribed solution is to install a C/C++ compiler, either Microsoft Visual C++, or MinGW (an open-source project). However, installing and configuring either is prohibitively difficult. (Edit 2014: Microsoft have published a special C++ compiler for Python 2.7)
The easiest solution is to use Christoph Gohlke’s Windows installers (.msi) for popular Python packages. He builds installers for Python 2.x and 3.x, 32 bit and 64 bit. You can download them from http://www.lfd.uci.edu/~gohlke/pythonlibs/
If you too think “Error: Unable to find vcvarsall.bat” is a ludicrously cryptic and unhelpful message, then please comment on the bug at http://bugs.python.org/issue2943 to replace it with a more helpful and user-friendly message.
For comparison, Ruby ships with a package manager Gem and offers a quasi-official C/C++ compiler, DevKit. If you try to install a package without it, you see this helpful friendly useful message:
You’ll need to install a Microsoft compiler, compatible with the compiler used to build Python. This means you need Visual C++ 2008 (or newer, with some tweaking).
Microsoft now supplies a bundled compiler and headers just to be able to compile Python extensions, at the memorable URL:
This is a relatively small package; 85MB to download, installable without admin privileges, no reboot required. The name is a little misleading, the compiler will work for any Python version originally compiled with Visual C++ 2008, not just Python 2.7.
If you start a Python interactive prompt or print sys.version, look for the MSC version string; if it is MSC v.1500 you can use this tool.
Microsoft has released a compiler package for Python 2.7 to make it easier for people to build and distribute their C extension modules on Windows. The Microsoft Visual C++ Compiler for Python 2.7 (a.k.a. VC9) is available from: http://aka.ms/vcpython27
This package contains all the tools and headers required to build C extension modules for Python 2.7 32-bit and 64-bit (note that some extension modules require 3rd party dependencies such as OpenSSL or libxml2 that are not included). Other versions of Python built with Visual C++ 2008 are also supported, so “Python 2.7” is just advertising – it’ll work fine with 2.6 and 3.2.
Note that you need to have setuptools 6.0 or newer installed (listed in the system requirements on the download page). The project you are installing must use setuptools.setup(), not distutils or the auto-detection won’t work.
Microsoft has stated that they want to keep the URL stable, so that automated scripts can reference it easily.
I just had this same problem, so I’ll tell my story here hoping it helps someone else with the same issues and save them the couple of hours I just spent:
I have mingw (g++ (GCC) 4.6.1) and python 2.7.3 in a windows 7 box and I’m trying to install PyCrypto.
It all started with this error when running setup.py install:
error: Unable to find vcvarsall.bat
Easily solved after googling the error by specifying mingw as the compiler of choice:
setup.py install build --compiler=mingw32
The problem is that then I got a different error:
configure: error: cannot run C compiled programs.
It turns out that my anti-virus was blocking the execution of a freshly compiled .exe. I just disabled the anti-virus “resident shield” and went to the next error:
cc1.exe: error: unrecognized command line option '-mno-cygwin'
error: command 'gcc' failed with exit status 1
This solved it: “Either install a slightly older version of MinGW, or edit distutils\cygwinccompiler.py in your Python directory to remove all instances of -mno-cygwin.” (from here)
I have python 2.73 and windows 7 .The solution that worked for me was:
Added mingw32’s bin directory to environment variable: append PATH with C:\programs\mingw\bin;
Created distutils.cfg located at C:\Python27\Lib\distutils\distutils.cfg containing:
[build]
compiler=mingw32
To deal with MinGW not recognizing the -mno-cygwin flag anymore, remove the flag in C:\Python27\Lib\distutils\cygwincompiler.py line 322 to 326, so it looks like this:
Look in the setup.py file of the package you are trying to install. If it is an older package it may be importing distutils.core.setup() rather than setuptools.setup().
I ran in to this (in 2015) with a combination of these factors:
Trying to do python setup.py build rather than using pip.
If you use a recent version of pip, it will force (monkeypatch) the package to use setuptools, even if its setup.py calls for distutils. However, if you are not using pip, and instead are just doing python setup.py build, the build process will use distutils.core.setup(), which does not know about the compiler install location.
Solution
Step 1: Open the appropriate Visual C++ 2008 Command Prompt
Open the Start menu or Start screen, and search for “Visual C++ 2008 32-bit Command Prompt” (if your python is 32-bit) or “Visual C++ 2008 64-bit Command Prompt” (if your python is 64-bit). Run it. The command prompt should say Visual C++ 2008 … in the title bar.
Step 2: Set environment variables
Set these environment variables in the command prompt you just opened.
cd to the package you want to build, and run python setup.py build, then python setup.py install. If you want to install in to a virtualenv, activate it before you build.
Maybe somebody can be interested, the following worked for me for the py2exe package.
(I have windows 7 64 bit and portable python 2.7, Visual Studio 2005 Express with Windows SDK for Windows 7 and .NET Framework 4)
File"numpy\core\setup.py", line 686,in get_mathlib_info
raiseRuntimeError("Broken toolchain: cannot link a simple C program")RuntimeError:Broken toolchain: cannot link a simple C program
I spent almost 2 days figuring out how to fix this problem in my python 3.4 64 bit version: Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Solution 1, hard: (before reading this, read first Solution 2 below)
Finally, this is what helped me:
create manually file vcvars64.bat in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64 which contains CALL "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x64 or other path depending on where you have yours installed
after that I tried to pip install numpy but received the following error:
File "numpy\core\setup.py", line 686, in get_mathlib_info
raise RuntimeError("Broken toolchain: cannot link a simple C program")
RuntimeError: Broken toolchain: cannot link a simple C program
finally after pip install numpy command my avast antivirus tried to interfere into the installation process, but i quickly disabled it
It took very long – several minutes for numpy to compile, I even thought that there was an error, but finally everything was ok.
Solution 2, easy:
(I know this approach has already been mentioned in a highly voted answer, but let me repeat since it really is easier)
After going through all of this work I understood that the best way for me is just to use already precompiled binaries from http://www.lfd.uci.edu/~gohlke/pythonlibs/ in future. There is very small chance that I will ever need some package (or a version of a package) which this site doesn’t contain. The installation process is also much quicker this way. For example, to install numpy:
donwload numpy‑1.9.2+mkl‑cp34‑none‑win_amd64.whl (if you have Python 3.4 64-bit) from that site
in command prompt or powershell install it with pip pip install numpy‑1.9.2+mkl‑cp34‑none‑win_amd64.whl (or full path to the file depending how command prompt is opened)
I encountered this issue when I tried to install numpy library on my python 3.5. The solution is to install VS2015. I had VS2008, 2012, 2013, none of which is compatible with python 3.5. Apparently newer version of python has dependency on newer versions of VS.
Also make sure C++ Common Tools are installed with Visual Studio.
I tried all the above answers, and found all of them not to work, this was perhaps I was using Windows 8 and had installed Visual Studio 2012. In this case, this is what you do.
The vcvarsall.bat file is located here:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC
Simply select the file, and copy it.
Then go to this directory:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools
You can download the free Visual C++ 2008 Express Edition from http://go.microsoft.com/?linkid=7729279, which will set the VS90COMNTOOLS environment variable during installation and therefore build with a compatible compiler.
As @PiotrDobrogost mentioned in a comment, his answer to this other question goes into details about why Visual C++ 2008 is the right thing to build with, but this can change as the Windows build of Python moves to newer versions of Visual Studio: Building lxml for Python 2.7 on Windows
但是，这不会为我安装，安装程序返回了错误installation failed with return code 5100。我在以下链接中找到了解决方案：http : //support.microsoft.com/kb/2717426。简而言之，如果安装了x86和x64 Microsoft Visual C ++ 2010 Redistributable的较新版本，它们将与SDK安装程序中的版本冲突，因此需要先进行卸载。
然后安装了SDK，但是我注意到vcvars64.bat仍然不存在C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin，也没有其子文件夹。vcvarsall.bat运行vcvars64批处理文件，因此如果没有该文件，python软件包仍将无法安装（我忘记了此时显示的错误）。
I had this problem using Python 3.4.1 on Windows 7 x64, and unfortunately the packages I needed didn’t have suitable exe or wheels that I could use. This system requires a few ‘workarounds’, which are detailed below (and TLDR at bottom).
Using the info in Jaxrtech’s answer above, I determined I needed Visual Studio C++ 2010 (sys.version return MSC v.1600), so I installed Visual C++ 2010 Express from the link in his answer, which is http://go.microsoft.com/?linkid=9709949. I installed everything with updates, but as you can read below, this was a mistake. Only the original version of Express should be installed at this time (no updated anything).
vcvarsall.bat was now present, but there was a new error when installing the package, query_vcvarsall raise ValueError(str(list(result.keys())))ValueError: [u'path']. There are other stackoverflow questions with this error, such as Errors while building/installing C module for Python 2.7
This would not install for me though, and the installer returned the error installation failed with return code 5100. I found the solution at the following link: http://support.microsoft.com/kb/2717426. In short, if newer versions of x86 and x64 Microsoft Visual C++ 2010 Redistributable’s are installed, they conflict with the ones in SDK installer, and need uninstalling first.
The SDK then installed, but I noticed vcvars64.bat still did not exist in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin, nor its subfolders. vcvarsall.bat runs the vcvars64 batch file, so without it, the python package still wouldn’t install (I forgot the error that was shown at this time).
I then found some instructions here: http://www.cryptohaze.com/wiki/index.php/Windows_7_Build_Setup#Download_VS_2010_and_Windows_SDK_7.1
Following the instructions, I had already installed Express and 7.1 SDK, so installed SDK 7.1 SP1, and did the missing header file fix. I then manually created vcvars64.bat with the content CALL setenv /x64. I will paste all those instructions here, so they don’t get lost.
And, bloody hell, fix the missing batch file for VS2010 Express. This
is getting downright absurd.
In C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64,
create “vcvars64.bat” with the following (you will need to be running
as administrator):
Never mind this question. Somebody here noticed this item on the menu: Start->All Programs->Microsoft Windows SDK v7.1 ->Windows SDK 7.1 Command Prompt
This runs a batch job that appears to set up a working environment for the compiler. From that prompt, you can type “setup.py build” or “setup.py install”.
I opened the Windows SDK 7.1 Command Prompt as instructed, and used it to run easy_install on the python package. And at last, success!
TLDR;
Install Visual Studio Express 2010 (preferably without updated redistributables or SQL server).
Install Windows 7.1 SDK
Instal SDK 7.1 SP1 update, and VS2010 SP1 header file fix (this step may not be required).
Manually create C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\vcvars64.bat with content CALL setenv /x64
Start->All Programs->Microsoft Windows SDK v7.1 ->Windows SDK 7.1 Command Prompt to open special x64 command prompt, which can then be used with python/easy_install/pip/etc (including those in virtual_envs).
回答 17
下面的步骤为我解决了这个问题，我试图用cython扩展创建安装程序。
安装适用于Python 2.7的Microsoft Visual C ++编译器
默认安装位置为@ C：\ Users \ PC-user \ AppData \ Local \ Programs \ Common \ Microsoft \ Visual C ++ for Python。这实际上可以解决此问题，请在继续操作之前进行一次测试。
Below steps fixed this issue for me, I was trying to create setup with cython extension.
Install Microsoft Visual C++ Compiler for Python 2.7
The default install location would be @
C:\Users\PC-user\AppData\Local\Programs\Common\Microsoft\Visual C++
for Python This might actually fix the issue, test once before proceeding.
If it fails, Check where in VC++
for python vcvarsall.bat file is located
Open the msvc9compiler.py
file of distutils package in notepad.
In my box this was @
C:\Anaconda2\Lib\distutils\msvc9compiler.py find_vcvarsall function
in this file, determine the version of VC by printing out version
argument. For Python 2.7 it’s likely to be 9.0
Now create an
environment variable VS90COMNTOOLS, Pointing to
C:\Users\PC-user\AppData\Local\Programs\Common\Microsoft\Visual C++
for Python\9.0\VC\bin
For some reason distutils expects the
vcvarsall.bat file to be within VC dir, but VC++ for python tools
has it in the root of 9.0 To fix this, remove “VC” from the
path.join (roughly around line 247)
I tried many solutions but only one worked for me, the install of Microsoft Visual Studio 2008 Express C++.
I got this issue with a Python 2.7 module written in C (yEnc, which has other issues with MS VS). Note that Python 2.7 is built with MS VS 2008 version, not 2010!
Despite the fact it’s free, it is quite hard to find since MS is promoting VS 2010.
Still, the MSDN official very direct links are still working: check https://stackoverflow.com/a/15319069/2227298 for download links.
I got the same problem and have solved it at the moment.
“Google” told me that I need to install “Microsoft Visual C++ Compiler for Python 2.7”. I install not only the tool, but also Visual C++ 2008 Reditributable, but it didn’t help. I then tried to install Visual C++ 2008 Express Edition. And the problem has gone!
Just try to install Visual C++ 2008 Express Edition!
calling import setuptools will monkey patch distutils to force compatibility with Visual Studio. Calling vcvars32.bat manually will setup the virtual environment and prevent other common errors the compiler will throw. For VS 2017 the file is located at
Use this link to download and install Visual C++ 2015 Build Tools. It will automatically download visualcppbuildtools_full.exe and install Visual C++ 14.0 without actually installing Visual Studio. After the installation completes, retry pip install and you won’t get the error again.
I have tested it on following platform and versions:
Python 3.6 on Windows 7 64-bit
Python 3.7 on Windows Server 2016 (64-bit system)
Python 3.8 on Windows 10 64-bit
回答 26
如果要在未安装Visual Studio 的Windows机器上安装pyodbc，则另一个选择是使用二进制发行版手动安装pyodbc。
If you’re looking to install pyodbc on a Windows box that doesn’t have Visual Studio installed another option is to manually install pyodbc using the binary distribution.
This is particularly useful if you do not have administrator privileges on the machine you’re working with and are trying to set up a virtualenv.
Steps:
Download the latest Windows installer from here (pyodbc-X.X.X.win-Y-py2.7.exe)
Open the installer executable using 7-Zip (or WinRAR or whatever)
Extract pyodbc.pyd and pyodbc-X.X.X-py2.7.egg-info and place them in [python installation directory or virtualenv]\Lib\site-packages
There is no step 4 :)
回答 27
使用Python 3.4，依赖关系依赖于Visual Studio2010。安装Visual C ++ 2010 Express对我来说解决了这个问题。
The answer given by @monkey is one of the correct ones, but it is incomplete.
In case you’d like to use MinGW, you should select the C, C++ and also other development tools suggested during the MinGW installation process to also get “make.exe.”
You must also have the path set to make.exe in the env.
To complete his answer, here are the steps:
Add mingw32’s bin directory to your environment variables
Append C:\Programs\MinGW\bin;C:\Programs\MinGW\msys\1.0\bin; to the PATH
Edit (create if it doesn’t exist) the distutils.cfg file located at C:\Python26\Lib\distutils\distutils.cfg to be:
[build]
compiler=mingw32
Make sure the environment variables is set by opening a new cmd.exe.
Then delete also the containing directory, e.g. /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/my_module-0.1.egg/ on macOS. It has no files, but Python will still import an empty module:
>>> import my_module
>>> my_module.__file__
None
Once deleted, Python shows:
>>> import my_module
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'my_module'
Check, how is your installed package named from pip point of view:
$ pip freeze
This shall list names of all packages, you have installed (and which were detected by pip).
The name can be sometime long, then use just the name of the package being shown at the and after #egg=. You can also in most cases ignore the version part (whatever follows == or -).
Then uninstall the package:
$ pip uninstall package.name.you.have.found
If it asks for confirmation about removing the package, then you are lucky guy and it will be removed.
pip shall detect all packages, which were installed by pip. It shall also detect most of the packages installed via easy_install or setup.py, but this may in some rare cases fail.
Here is real sample from my local test with package named ttr.rdstmc on MS Windows.
All what is written above still applies, anyway, there are small modifications available now.
Install pip in python 2.7.9 and python 3.4
Recent python versions come with a package ensurepip allowing to install pip even when being offline:
$ python -m ensurepip –upgrade
On some systems (like Debian Jessie) this is not available (to prevent breaking system python installation).
Using grep or find
Examples above assume, you have grep installed. I had (at the time I had MS Windows on my machine) installed set of linux utilities (incl. grep). Alternatively, use native MS Windows find or simply ignore that filtering and find the name in a bit longer list of detected python packages.
If a file is installed which includes spaces or other special
characters, the xargs command will fail, and delete any
files/directories which matched the individual words.
the -r in rm -rf is unnecessary and at worst could delete things you
don’t want to.
Instead, for unix-like:
sudo python setup.py install --record files.txt
# inspect files.txt to make sure it looks ok. Then:
tr '\n' '\0' < files.txt | xargs -0 sudo rm -f --
There are also unsolvable problems with uninstalling setup.py install which won’t bother you in a typical case. For a more complete answer, see this wiki page:
Now python gives you the choice to install pip during the installation (I am on Windows, and at least python does so for Windows!). Considering you had chosen to install pip during installation of python (you don’t actually have to choose because it is default), pip is already installed for you. Then, type in pip in command prompt, you should see a help come up. You can find necessary usage instructions there. E.g. pip list shows you the list of installed packages. You can use
The lazy way: simply uninstall from the Windows installation menu (if you’re using Windows), or from the rpm command, provided you first re-install it after creating a distribution package.
If you still have files that are supposed to be deleted after re-installing a package, make sure the folder build is also deleted. Therefore, assuming that pkg is the package you want to delete:
I had run “python setup.py install” at some point in the past accidentally in my global environment, and had much difficulty uninstalling. These solutions didn’t help. “pip uninstall ” didn’t work with “Can’t uninstall ‘splunk-appinspect’. No files were found to uninstall.” “sudo pip uninstall ” didn’t work “Cannot uninstall requirement splunk-appinspect, not installed”. I tried uninstalling pip, deleting the pip cache, searching my hard drive for the package, etc…
“pip show ” eventually led me to the solution, the “Location:” was pointing to a directory, and renaming that directory caused the packaged to be removed from pip’s list. I renamed the directory back, and it didn’t reappear in pip’s list, and now I can reinstall my package in a virtualenv.
I had run python setup.py install once in my PyCharm, it installs all the packages into my conda base environment. Later when I want to remove all these packages, pip uninstall does not work. I had to delete them from /anaconda3/lib/python3.7/site-packages manually :(
So I don’t see the reason why they use setup.py instead of writing requirements.txt file. The requirement file can be used to install packages in virtual environment and won’t mess with system python packages.
setup.py is a python file, which usually tells you that the module/package you are about to install has been packaged and distributed with Distutils, which is the standard for distributing Python Modules.
This allows you to easily install Python packages. Often it’s enough to write:
$ pip install .
pip will use setup.py to install your module. Avoid calling setup.py directly.
from setuptools import setup
setup(
name='foo',
version='1.0',
description='A useful module',
author='Man Foo',
author_email='foomail@foo.com',
packages=['foo'],#same as name
install_requires=['bar','greek'],#external packages as dependencies)
It helps to install a python package foo on your machine (can also be in virtualenv) so that you can import the package foo from other projects and also from [I]Python prompts.
It does the similar job of pip, easy_install etc.,
Using setup.py
Let’s start with some definitions:
Package – A folder/directory that contains __init__.py file. Module – A valid python file with .py extension. Distribution – How one package relates to other packages and modules.
Let’s say you want to install a package named foo. Then you do,
Instead, if you don’t want to actually install it but still would like to use it. Then do,
$ python setup.py develop
This command will create symlinks to the source directory within site-packages instead of copying things. Because of this, it is quite fast (particularly for large packages).
from setuptools import setup
setup(
name='foo',
version='1.0',
description='A useful module',
author='Man Foo',
author_email='foomail@foo.com',
packages=['foo'], #same as name
install_requires=['bar', 'greek'], #external packages as dependencies
scripts=[
'scripts/cool',
'scripts/skype',
]
)
Add more stuff to (setup.py) & make it decent:
from setuptools import setup
with open("README", 'r') as f:
long_description = f.read()
setup(
name='foo',
version='1.0',
description='A useful module',
license="MIT",
long_description=long_description,
author='Man Foo',
author_email='foomail@foo.com',
url="http://www.foopackage.com/",
packages=['foo'], #same as name
install_requires=['bar', 'greek'], #external packages as dependencies
scripts=[
'scripts/cool',
'scripts/skype',
]
)
The long_description is used in pypi.org as the README description of your package.
And finally, you’re now ready to upload your package to PyPi.org so that others can install your package using pip install yourpackage.
First step is to claim your package name & space in pypi using:
$ python setup.py register
Once your package name is registered, nobody can claim or use it. After successful registration, you have to upload your package there (to the cloud) by,
$ python setup.py upload
Optionally, you can also sign your package with GPG by,
setup.py is Python’s answer to a multi-platform installer and make file.
If you’re familiar with command line installations, then make && make install translates to python setup.py build && python setup.py install.
Some packages are pure Python, and are only byte compiled. Others may contain native code, which will require a native compiler (like gcc or cl) and a Python interfacing module (like swig or pyrex).
setup.py is a Python script that is usually shipped with libraries or programs, written in that language. It’s purpose is the correct installation of the software.
Many packages use the distutils framework in conjuction with setup.py.
setup.py can be used in two scenarios , First, you want to install a Python package. Second, you want to create your own Python package. Usually standard Python package has couple of important files like setup.py, setup.cfg and Manifest.in. When you are creating the Python package, these three files will determine the (content in PKG-INFO under egg-info folder) name, version, description, other required installations (usually in .txt file) and few other parameters. setup.cfg is read by setup.py while package is created (could be tar.gz ). Manifest.in is where you can define what should be included in your package. Anyways you can do bunch of stuff using setup.py like
python setup.py build
python setup.py install
python setup.py sdist <distname> upload [-r urltorepo] (to upload package to pypi or local repo)
There are bunch of other commands which could be used with setup.py . for help
python setup.py --help-commands
回答 6
当您通过setup.py打开终端（Mac，Linux）或命令提示符（Windows）下载软件包时。使用“ cd Tab”按钮并为您提供帮助，将路径设置为已下载文件的文件夹的正确位置，该文件夹位于setup.py：
When you download a package with setup.py open your Terminal (Mac,Linux) or Command Prompt (Windows). Using cd and helping you with Tab button set the path right to the folder where you have downloaded the file and where there is setup.py :
To install a Python package you’ve downloaded, you extract the archive and run the setup.py script inside:
python setup.py install
To me, this has always felt odd. It would be more natural to point a package manager at the download, as one would do in Ruby and Nodejs, eg. gem install rails-4.1.1.gem
A package manager is more comfortable too, because it’s familiar and reliable. On the other hand, each setup.py is novel, because it’s specific to the package. It demands faith in convention “I trust this setup.py takes the same commands as others I have used in the past”. That’s a regrettable tax on mental willpower.
I’m not saying the setup.py workflow is less secure than a package manager (I understand Pip just runs the setup.py inside), but certainly I feel it’s awkard and jarring. There’s a harmony to commands all being to the same package manager application. You might even grow fond it.
setup.py is a Python file like any other. It can take any name, except by convention it is named setup.py so that there is not a different procedure with each script.
Most frequently setup.py is used to install a Python module but server other purposes:
Modules:
Perhaps this is most famous usage of setup.py is in modules. Although they can be installed using pip, old Python versions did not include pip by default and they needed to be installed separately.
If you wanted to install a module but did not want to install pip, just about the only alternative was to install the module from setup.py file. This could be achieved via python setup.py install. This would install the Python module to the root dictionary (without pip, easy_install ect).
This method is often used when pip will fail. For example if the correct Python version of the desired package is not available via pipperhaps because it is no longer maintained, , downloading the source and running python setup.py install would perform the same thing, except in the case of compiled binaries are required, (but will disregard the Python version -unless an error is returned).
Another use of setup.py is to install a package from source. If a module is still under development the wheel files will not be available and the only way to install is to install from the source directly.
Building Python extensions:
When a module has been built it can be converted into module ready for distribution using a distutils setup script. Once built these can be installed using the command above.
A setup script is easy to build and once the file has been properly configured and can be compiled by running python setup.py build (see link for all commands).
Once again it is named setup.py for ease of use and by convention, but can take any name.
Cython:
Another famous use of setup.py files include compiled extensions. These require a setup script with user defined values. They allow fast (but once compiled are platform dependant) execution. Here is a simple example from the documentation:
from distutils.core import setup
from Cython.Build import cythonize
setup(
name = 'Hello world app',
ext_modules = cythonize("hello.pyx"),
)
This can be compiled via python setup.py build
Cx_Freeze:
Another module requiring a setup script is cx_Freeze. This converts Python script to executables. This allows many commands such as descriptions, names, icons, packages to include, exclude ect and once run will produce a distributable application. An example from the documentation:
import sys
from cx_Freeze import setup, Executable
build_exe_options = {"packages": ["os"], "excludes": ["tkinter"]}
base = None
if sys.platform == "win32":
base = "Win32GUI"
setup( name = "guifoo",
version = "0.1",
description = "My GUI application!",
options = {"build_exe": build_exe_options},
executables = [Executable("guifoo.py", base=base)])
This can be compiled via python setup.py build.
So what is a setup.py file?
Quite simply it is a script that builds or configures something in the Python environment.
A package when distributed should contain only one setup script but it is not uncommon to combine several together into a single setup script. Notice this often involves distutils but not always (as I showed in my last example). The thing to remember it just configures Python package/script in some way.
It takes the name so the same command can always be used when building or installing.
To make it simple, setup.py is run as "__main__" when you call the install functions the other answers mentioned. Inside setup.py, you should put everything needed to install your package.
Common setup.py functions
The following two sections discuss two things many setup.py modules have.
setuptools.setup
This function allows you to specify project attributes like the name of the project, the version…. Most importantly, this function allows you to install other functions if they’re packaged properly. See this webpage for an example of setuptools.setup
These attributes of setuptools.setup enable installing these types of packages:
In an ideal world, setuptools.setup would handle everything for you. Unfortunately this isn’t always the case. Sometimes you have to do specific things, like installing dependencies with the subprocess command, to get the system you’re installing on in the right state for your package. Try to avoid this, these functions get confusing and often differ between OS and even distribution.
