Rationalizing Python packaging

This.

I use 'virtualenv' + 'pip' and it SIGNIFICANTLY increased the utility of Python for me.

Major advantages of doing 'sandboxed' approach:

* All the systems I use will end up using as close to the same software as possible. I deal with various versions of Redhat, my Fedora desktop, and a couple Debian/Ubuntu machines. Using PIP + Virtualenv ensures that the software matches all these machines as closely as possible.

* The majority of Python libraries and whatnot are not packaged by distributions. So if I tried to use it I would be forced to manage a huge amount of the software manually or through ad-hoc scripts and try to manage all that stuff manually.

* For the software that distributions DO actually package they have random versions that are usually going to be mostly worthless for what I need to do.

* I can trivially setup multiple 'sandboxed' environments for different projects. I don't have to use full fledged virtual machines. I can have a different project and different set of software enabled for different terminals. It's extremely easy and, much more, it's extremely _quick_. Do not underestimate the utility of being able to do things very quickly or easily. This leads to allowing you do to new things that are not possible with a more cumbersome setup.

* I can maintain a particular environment for a particular application that I've worked on. If I want to update my default virtualenv that I use for ipython and such things then I don't have to worry about that breaking some old Flask project I haven't worked on in months.

That's the stuff I can think of off the top of my head. The 'virtualenv' and 'pip' approach is a huge win. It's too bad that this sort of thing is available for everything. Even if you don't have a easy way to 'sandbox' things there are huge advantages in being able to use alternative packaging schemes for commonly used Linux software.

For example, If I had to depend on apt-get or yum to install Emacs modules for me I would never actually have used Emacs. Emacs would be almost completely unusable.

Every time I tried to use that editor in the past I would get thwarted by the differences in different Linux distributions I would be forced to have to use it on. The Emacs versions themselves, the modules available, and the versions available on different systems would be virtually at random. And it's not even a issue of 'Use tramp' (which I do use all the time), 'put emacs in tmux/screen'(GUI version of Emacs significantly better then terminal version), or 'use Emacs over X over ssh'(X networking is miserable).

I use different workstations. I want to use it on my work laptop, my work workstation, my home desktop, my home laptop, and my backup remote system I have setup for work when I can't get to any of the above. Even getting really decent python support for Emacs was pretty miserable.

Nowadays the most painful thing to deal with is installing Emacs if the distribution doesn't offer a new enough version. I can us e git for the actual configs and make sure they are available on all the systems and I can depend on Melpa and Emacs package management to automatically setup everything the as close to the same way on all my systems as possible. If I have a issue I can google it and even if the blog post or question gets asked/answered for a user on a Windows machine or a OS X system I can still follow along on my Linux systems with the same commands and whatnot and it will usually work out fine.

Nowadays people new to Emacs can be told: "Install Emacs. Make sure it's 24 or newer. Make sure you have 'package' enabled, add gnu, marmalade, and melpa repos, and then install the emacs-starter-kit from that and you are about 90% the way there." I don't have to go into specifics on whether they are using Ubuntu, Debian, Redhat, Fedora, or Arch. It's irrelevant. Even the same advice applies mostly the same to people using OS X and Windows.

Something like that isn't even remotely possible if you try to depend on a Linux distribution's provided emacs modules. I run into the same issues with Java or Perl or whatever else I try to use on Linux. It's almost always a huge advantage to ignore the distribution packaged versions of software as much as possible, unless you are dealing with major popular things and that sort of thing.