There really isn't a single "answer" to this question, but there are definitely some helpful concepts that can help you to come to a decision.
The first question that needs to be answered in your use case is "Do I want to use the system Python?" If you want to use the Python distributed with your operating system, then using the apt-get install method may be just fine. Depending on the operating system distribution method though, you still have to ask some more questions, such as "Do I want to install multiple versions of this package?" If the answer is yes, then it is probably not a good idea to use something like apt. Dpkg pretty much will just untar an archive at the root of the filesystem, so it is up to the package maintainer to make sure the package installs safely under very little assumptions. In the case of most debian packages, I would assume (someone can feel free to correct me here) that they simply untar and provide a top level package.
For example, say the package is "virtualenv", you'd end up with /usr/lib/python2.x/site-packages/virtualenv
. If you install it with easy_install
you'd get something like /usr/lib/python2.x/site-packages/virtualenv.egg-link
that might point to /usr/lib/python2.x/site-packages/virtualenv-1.2-2.x.egg
which may be a directory or zipped egg. Pip does something similar although it doesn't use eggs and instead will place the top level package directly in the lib
directory.
I might be off on the paths, but the point is that each method takes into account different needs. This is why tools like virtualenv are helpful as they allow you to sandbox your Python libraries such that you can have any combination you need of libraries and versions.
Setuptools also allows installing packages as multiversion which means there is not a singular module_name.egg-link
created. To import those packages you need to use pkg_resources and the __import__
function.
Going back to your original question, if you are happy with the system python and plan on using virtualenv and pip to build environments for different applications, then installing virtualenv and / or pip at the system level using apt-get seems totally appropriate. One word of caution though is that if you plan on upgrading your distributions Python, that may have a ripple effect through your virtualenvs if you linked back to your system site packages.
I should also mention that none of these options is inherently better than the others. They simply take different approaches. Using the system version is an excellent way to install Python applications, yet it can be a very difficult way to develop with Python. Easy install and setuptools is very convenient in a world without virtualenv, but if you need to use different versions of the same library, then it also become rather unwieldy. Pip and virtualenv really act more like a virtual machine. Instead of taking care to install things side by side, you just create an whole new environment. The downside here is that 30+ virtualenvs later you might have used up quite bit of diskspace and cluttered up your filesystem.
As you can see, with the many options it is difficult to say which method to use, but with a little investigation into your use cases, you should be able to find a method that works.