Also note that the default Django template is showing it's age. I don't think it's ever been updated and it contains a few faux-pas to look out for. In particular, it starts you off inside a python package (__init__.py file), which is highly confusing. If you later want to treat your Django project as a normal Python project, you need to create a setup.py file. But this file would be one directory up from the project directory ... which is outside of your Django project. Django puts the directory one level up on your PYTHONPATH to compensate for this, with the assumption that part of your project lives outside of version-control, etc. The solution is to remember to put the directory above the directory that the project lives in version-control and treat it as part of the project. Although then you have to put a library location on your PATH to run the manage.py commands, since this file won't work if placed in your projects /bin directory.
(Speaking of /bin directories, it's always bugged me that Rails renamed this directory to /scripts ... if it's executable, it goes in /bin, it makes no sense to split executables based on arbitrary implementation details)
The question is, why use the framework to create the layout of project which happens to depend upon that framework at all? Instead, use a generic project templating tool to create the layout, then it's easy to choose alternate starting points depending upon what you need in your project. In Python, 'paster' is commonly used for this. It lets you create projects that depend upon TurboGears or Zope or Plone or Grok or even plain old Python projects which don't depend upon a full framework.
Heh, like pip, it relies on the previous package management tool (gems and easy_install) to install itself.
rip isn't just a mix of pip and virtualenv though, it's also got bits of functionality from virtualenvwrapper (manages multiple envs) and buildout (plugins) mixed in there.
There is no way to work with gems in a development format? e.g. straight from version control?
I like Buildout's approach of doing script generation better though, since it allows for multiple working sets of packages within the same environment. And you can manage stuff besides just language-specific packages, such as database installs, config files, etc, etc. Plus you can manage libraries from more than just one language - perfect for those franken-Python-Perl-Ruby projects.
Looks like a big improvement over the rails/gem_dependencies sillyness of embedding a package management tool into a web framework though!
If you install Python 3 with "make fullinstall" then the binary will be named just "python". I've always used just "#!/usr/bin/env python" and just kept track of what version of Python a collection of code was targeted for. Changing all scripts from "#!/usr/bin/env python3.0" to ""#!/usr/bin/env python3.1" and so on is too cumbersome.
But it depends upon how you manage your code - whether it's just a few loose scripts, part of a larger project, a web app or a desktop app or a command-line script, or what your deployment and install processes looks like, etc. etc. I usually install my Python scripts with Buildout these days, so I let Buildout autogenerate the shebangs to point to the required Python installation.
(Speaking of /bin directories, it's always bugged me that Rails renamed this directory to /scripts ... if it's executable, it goes in /bin, it makes no sense to split executables based on arbitrary implementation details)