Tarek Ziadé

Interesting remark from the author in a reply to one of the comments: "Most server-side Mozilla projects are moving to a Python-based eco-system."[1] [1] http://tarekziade.wordpress.com/2011/07/12/firefox-sync-python/#commen…

For anyone who wants to help Python wrt packaging, get behind [Tarek] and his work on distutils2. That's the future of Python packaging (with Guido's blessing) [^1]. More info on python packaging temporarily at http://guide.python-distribute.org/ . There's also a [packaging discussion group] which seems to be primarily focused on distutils2 development. [Tarek]: http://ziade.org/ [^1]: http://tarekziade.wordpress.com/2010/03/03/the-fate-of-distutils-pycon… [packaging discussion group]: http://groups.google.com/group/the-fellowship-of-the-packaging/topics?…

Absolutely. It's ok if you're installing Django to run some 3rd party software but if you're actually building something you need to support it's important to have more control over your environment/libraries than the system-level package manager provides. The author gets it right on the Ruby side but their lack of experience on the python side here is showing. Pip and virtualenv are definitely the way to go today. For tomorrow you should keep your eye on the packaging PEP and the Hitchhiker's guide to packaging: http://guide.python-distribute.org/introduction.html#current-state-of-… http://tarekziade.wordpress.com/2010/02/10/pep-345-and-386-accepted-su… It's confusing but improving quickly. I know it took me quite a while to figure out what the right way to do things in python was. This is also where rails' conventions help. As good as people say the documentation for Django is, many searches pull up blog posts from 2006 which were right for their time but now are simply outdated. That being said, I think there has been a tremendous boost in Django activity in the past year or so. I feel like they are getting in front of the curve again.

> Well... hopefully R6 will pull things together a bit. Do you mean "R7"? Because R6 seems to have actually done the opposite. > Personally I'm not a real fan of cpan. The qualilty is sort of hit and miss. The hit-or-miss quality is a necessary "evil" for having something as good as the CPAN. Yes, it's got a lot of crap, but there are a lot of gems that save many people a lot of work. > I like python's approach better. The standard library is robust and broad enough to handle most things. It has been said that the Python standard lib is where modules go to die. Guido himself has implied [^1] that modules in the std lib already have one foot in the grave. [^1]: http://tarekziade.wordpress.com/2010/03/03/the-fate-of-distutils-pycon… The future of successful general purpose languages is to have a small core with a vibrant external "CPAN". There just aren't enough core developers to maintain a large high-quality batteries-included standard library of modules. Much better is a dedicated loosely-coupled mostly active community of maintainers -- maintaining the bits that they are personally interested in (which is exactly what the CPAN has).