Update instructions to use virtualenv, pip, and _not_ sudo

[altendky]

• virtualenv allows isolation of installation of Python projects. This is basically the only way to install packages 'right'. --user hazards mixing library versions unexpectedly and installing into the system can corrupt entire installations in Linux.
• pip should be called instead of calling setup.py directly so as to handle all dependencies at least. Also, don't use easy_install.
• Do not use sudo to install. It's not consistent but lots of people have destroyed their python installations by doing this. The issue is that you end up mixing pip package management with the Linux system's package management and they don't necessarily cooperate well.

[jbm950]

virtualenv allows isolation of installation of Python projects. This is basically the only way to install packages 'right'. --user hazards mixing library versions unexpectedly and installing into the system can corrupt entire installations in Linux.

To the first point, there are other ways that can work to install packages and not mix library versions. For instance there are people who will make a new linux virtual machine for each project they work on. Aside from that though the goal of the installation instructions is to be as minimalist as possible with as few external dependencies as possible. Since the repository is not dependent on virtualenv to work I think we want to try to keep the minimalist nature of the installation instructions and not force people to use additional tools.

pip should be called instead of calling setup.py directly so as to handle all dependencies at least. Also, don't use easy_install.

I personally don't have much experience with pip installation outside of pypi but in general I think pip is great. pip is still "relatively newer" and there are still python versions out there that don't come naturally with pip and so if we were to change the primary instructions to use pip I'd like an aside/note that if it's not installed the python setup.py install command will work as well (This may mean that we would not be able to put the dependencies in the setup.py file but if we switch to using pip for pyserial it would only be one additional command). Talking to Bob about easy_install, he says he got that from the pyserial documentation when he originally wrote the instructions and is ok updating it to use pip as that is currently what pyserial says to use too.

Do not use sudo to install. It's not consistent but lots of people have destroyed their python installations by doing this. The issue is that you end up mixing pip package management with the Linux system's package management and they don't necessarily cooperate well.

I would be ok removing this from the README. If people encounter errors here there is plenty of documentation in a google search on installing packages on unix systems.

I want to emphasize that we really do appreciate your assistance and I will try to be as responsive as possible.

[altendky]

A virtual machine doesn't help with the hazards in some Linux distributions of installing into the system Python. But sure, there are multiple solutions. I wish there was a good general page about this since it's really completely unrelated to any specific package, but I'm not aware of one.

I'll put in a PR to remove the sudo suggestion (and explicitly warn of the hazard) but the rest probably won't get as prioritized by me. We'll see.

I was really excited when I found this library. It's so nice to have an existing implementation to start with. Now I'm looking forward to sharing more with everyone. I'm glad your interested in all this.

Hmm, how about a reference to #python and a few options for web based IRC access? Let them (which means me too...) help people out directly.

[altendky]

Hmm, maybe the official one is ok. Starts with pip but points out that you might want to use easy_install sometimes. Suggests virtualenv as an option. Doesn't mention sudo but does offer --user (despite it's hazards). It also covers generic installation from source via several methods (local, remote, repositories) (though the explanation of the models would still be up to us).

I'm about to submit a significant rework. I understand it may be too much but figured I'd give us something concrete to discuss.