Virtualenv is a good thing. It can create independent virtual environments for various Python applications and is useful for development and deployment. In particular, the enhanced version of virtualenvwrapper is easy to use.
But it will also bring about the problem of the demon moth. For example, I have encountered this problem before:
Problem: The install_name_tool error occurs in virtualenv of Mac OS X 10.6 snow leopard.
Failed to create virtualenv under Mac OS X 10.6 SL, an install_name_tool error is returned. After searching for a long time, no feasible solution was found. All solutions point to one:
Install the latest version of xcode or its simplified command line tools package. However, the latest version of xcode or CLT must be upgraded to 10.7.3 or above...
Although the latest 10.8 ml product also sells 128 yuan, I just don't like to upgrade the system. Although the OS x upgrade is said to be smooth, I still need to back up the data for the sake of insurance, in addition, there will be a lot of applications to be upgraded after the system upgrade, Which is troublesome. I used Ubuntu 10.04 for two years and waited until the next lts 12.04 was released. In addition, many people report that the update speed is much slower after the ml upgrade, so I don't want to upgrade it any more.
Later, some people finally said that it is okay not to install the latest xcode. You only need to upgrade xcode to the highest version supported by the current system, so it took me one afternoon to download the highest version of xcode 3.2.6 that can be used in SL to install it.
When virtualenv encounters a non-pure Python package
Generally, installation of a python-only package in virtualenv is completely normal. It is convenient to use easy_install or Pip. By the way, I personally recommend PIP, which is much easier to use than easy_install.
The problem lies in the non-pure Python package. In this case, we usually need to compile some C or C ++ code to generate some libraries. For non-virtualenv, it is usually not troublesome. For example, Debian/Ubuntu can find the corresponding apt package for installation, and FreeBSD usually has the corresponding ports package for installation.
However, when virtualenv encounters a non-pure Python package, the problem arises.
Relatively speaking, Debian/Ubuntu will be slightly better. It is nothing more than installing some Dev packages in the main environment, then, you can use Pip/easy_install in virtualenv to automatically compile and install it.
For FreeBSD, the situation will be troublesome, because the source code is compiled by using ports, so no other Dev package can be installed. Therefore, you need to solve some Path Problems to compile it smoothly.
In fact, I have encountered and solved this problem before, but I can't remember how I solved it this time. I 've been tossing it for a long time, so I 'd better remember it for future reference.
Why is Windows not mentioned in Linux, FreeBSD, and Mac OS X discussed above? Of course, this is because we cherish SM and stay away from Ms. Using virtualenv in Windows is basically the same as finding it. There are no solutions to many problems...
Pysqlite installation error in virtualenv of FreeBSD 9
First, let's look at pysqlite.
In fact, Python 2.5 and above have built-in support for SQLite, but since I have been using sqlalchemy, it uses this library, so I still need to install it.
Directly in virtualenv:
pip install pysqlite
The compilation error will be reported. Find the header file not sqlite3.h.
Solution:
Workon yourenvpip install -- no-install pysqlite # This is the virtualenvwrapper command. If virtualenv is used, run the CD command directly to run cdvirtualenv build/pysqlitevim setup in the corresponding path. CFG # Remove the annotations in the include_dirs and library_dirs paths. Save and exit and reinstall Pip install pysqlite.
You can.
Gevent installation error in virtualenv of FreeBSD 9
The method is similar to the above, but this time you do not need to modify any files, but directly install them in build.
Workon yourenvpip install -- no-install gevent # This is the virtualenvwrapper command, if it is virtualenv, use the CD command to go to the corresponding path cdvirtualenv build/gevent # The following is the port location where libevent is located. Modify Python setup according to your own situation. PY install -- libevent/usr/ports/devel/libevent/work/libevent-1.4.14b-stable # The following sentence is just for some post-installation finishing work, such as clearing the build directory content and Other PIP install gevent
You can.