Great post. I would add:<p>* the site module, which is imported by default and is what is responsible for setting up the default sys.path. You can skip 'import site' by running python with the -S switch. the site module is written in python, so you can scan through it and understand how python starts up and inits.<p>* PYTHONSTARTUP env variable, which points to a python file that is run (like a bashrc, or AUTOEXEC.BAT, if you prefer) on interactive prompt startup. I use this to import custom paths and modules that I want to access from the REPL, such as Google App Engine<p>* I use pip with local repositories. clone the repos of the libs you need, and then pip install in the virtualenv from that local clone:<p><pre><code> $ pip install git+file:///Users/nik/.python-packages/tornado
</code></pre>
(note the triple slash). Or straight from GH:<p><pre><code> $ pip install git+git://nikcub@github.com/nikcub/tornado
</code></pre>
this can keep your versions in sync across all projects and virtualenvs and it means no re-downloading and you can setup and update projects while offline.<p>* don't store the actual project inside the virtualenv. the virtualenv provides the execution context (setup and torn down using the virtualenvwrapper helper scripts). a common practice is to place all your virtualenvs into a directory like ~/.virtualenvs. you should never have to cd into this dir, access it using the wrappers and pip. (edit: also agree with comment below that you shouldn't be sudo'ing).<p>* just a quick add, I think it is definitely worth learning how to install python from source.
A formidable effort.<p>It might be matter of taste but recommendations given starting from "Understanding the packages" and to "Install packages that need compiling" are almost harmful.<p>My preference:<p>* you should not care what is your `sys.path` looks like. You need it for debugging if something goes horribly wrong. A tutorial might mention it but things like `sys.path.insert(0,..)` should be avoided or accompanied with a big disclaimer (don't use nuclear weapons if you care about the future)<p>* the same goes for `PYTHONPATH`. It is a hack that rarely
needed<p>* don't use `sudo pip`. System packages should be managed by a system packager. Use `pip --user` or create a `virtualenv`<p>* `pip` can handle tarballs there is no need for `python setup.py install` in this case.<p>"Code Like a Pythonista: Idiomatic Python" is worth mentioning
<a href="http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html" rel="nofollow">http://python.net/~goodger/projects/pycon/2007/idiomatic/han...</a><p>Some third-party packages that could be listed (it is subjective):<p>bpython - interactive prompt; something for tests e.g., pytest, tox, selenium; sphinx - docs; lxml - xml/html, werkzeug - if you talking about web-development; SQLAlchemy - sql; Cython - C extension, ~ Python syntax; async. libs e.g., gevent, Twisted.
I'd love to have one of these for Ruby. Every time I want to try out something written in Ruby I run head-first in to the packaging problem - Debian and Ubuntu don't appear to like shipping a working gem (presumably because it conflicts with how apt likes to do things) and the documentation on how to resolve the resulting inscrutable error messages isn't particularly easy to find. The Mac is a bit better, but I still run in to problems far too often.<p>I'm pretty sure a "Ruby Ecosystem, An Introduction" guide is exactly what I need.
Have you thought about combining your work with Kenneth Reitz's Python Guide? <a href="https://github.com/kennethreitz/python-guide" rel="nofollow">https://github.com/kennethreitz/python-guide</a><p>It looks like you're covering a lot of the same ground.
> Choose Python 3 only if you need to and/or fully understand the implications.<p>I would apply the "if you need to" part to Python 2. "3 if you can, 2 if you must"
I think that
$ sudo apt-get install python-pip
is a bad idea.<p>You should not mix multiple packaging system on your operating system.
And more you can dammage it pip provide more recent package than your distro. And if you upgrade a lib that have an incompatibility with a part of the system, you can corrupt it. I have no example to give but I am sure you can find it... Ubuntu now have many tools written in python.<p>You should use pip inside a virtualenv only.
And, fortunatelly when you create a virtualenv, pip is installed in it, and you don't need to use the --distribute to have it.
Great post - I wish there was a unified resource for things like that for other languages/tools.<p>I would only add <i>iPython</i> - a must for any console adventures.
You really shouldn't tell people to go ask how to install Python on stackoverflow.com. Instead give them a few URLs to stackoverflow questions with the answer such as this one <a href="http://stackoverflow.com/questions/7538834/how-to-create-a-python-distribution-like-activepython" rel="nofollow">http://stackoverflow.com/questions/7538834/how-to-create-a-p...</a><p>Or even better, give them a stackoverflow search like this one <a href="http://stackoverflow.com/search?q=%5Bpython%5D+%22install+python%22" rel="nofollow">http://stackoverflow.com/search?q=%5Bpython%5D+%22install+py...</a><p>P.S. I think that your wiki page is a great idea and I'm going to write a custom one for our developer wiki.
Though the article claims to be targeted at users running on linux, most of the the info is still quite useful regardless of the platform - just figure out how to install python and and pip and the rest is pretty platform agnostic.
Nice article. I am bookmarking it.<p>Also The Zen of Python can always be accessed by this Easter egg<p><pre><code> >>> import this
</code></pre>
<a href="http://www.python.org/dev/peps/pep-0020/" rel="nofollow">http://www.python.org/dev/peps/pep-0020/</a>
I mostly dabble with python. I learned a little reading this, and it raised some questions for me. Is there a reason --distribute is not the default behavior of virtualenv? Is there a plan to incorporate the stuff virtualenvwrapper does into virtualenv (virtualenvwrapper is a pretty cumbersome name, if for no other reason)?
Thank you for this article.<p>As per the Pragmatic Programmer, I thought I would learn Python this year. It's been a tremendously <i>frustrating</i> experience getting a workable stack installed.<p>I wish the famous "<i>One -- and preferably only one -- obvious way to do it</i>" Python design philosophy extended to actually installing everything :(
Great article.<p>If you're on Ubuntu LTS you should install PIP from PyPI (easy_install pip), since the system package management version is outdated and it doesn't have the (very useful, since PyPI likes to go down) --use-mirrors install option. That would be my only recommendation.
I'm surprised nobody has mentioned pythonbrew.<p><a href="https://github.com/utahta/pythonbrew" rel="nofollow">https://github.com/utahta/pythonbrew</a><p>It's the Python version of RVM. It is higher level than even virtualenv, and in my opinion, the most seamless way to manage Python environments.
This is very good. I wish a resource like this was around when I was first learning Python. The difficulty of getting things to work <i>around</i> the language has always been a pretty stark contrast to the ease of the language itself.
Looks great. I've started turning my attention to python recently so skimming through this I can already see lots of stuff that'll be very useful. So much that perhaps a linked TOC at the top of the page could be an idea?
Thank you, thank you, thank you. I've been looking for something like this for ages. While Python the language is fantastic, I have found getting into the whole environment quite tricky so your guide is fantastic.
Great article. Is it just me or the prepend/append examples are swapped? ie. If you want to append TO your PYTHONPATH you should do PYTHONPATH=$PYTHONPATH:/some/new/path
NOTE: there's brokenness lurking in urllib and email modules. The python library modules are more often than not modeled on perfect reality rather than a pragmatic one (e.g., complete violations of RFCs). BTW, if one reads re.py in the dist, you'll notice that it hasn't been touched by Fredrik Lundh since 2001!<p>I should say I still love python. Its the most fun I've had programming next to Scheme, and well, NodeJS is kind of fun too (in an algol way).
would make a good idea for a startup...a Python host that has a simple checkbox interface for installing all this stuff.<p>That way you can get started with coding instead of having to install everything by yourself.
In the section of "The Development Environment" you should mention the buildout (<a href="http://www.buildout.org/" rel="nofollow">http://www.buildout.org/</a>). It is a very simple way to reproduce an enviroment.