Here are some of my favorite results.

Vanity

$ vanity vanity -v
     vanity-1.0.zip     2011-04-14      352
   vanity-1.1.0.zip     2011-10-26      139
   vanity-1.1.1.zip     2011-10-28      114
   vanity-1.1.2.zip     2011-10-28      145
vanity-1.2.0.tar.gz     2012-01-30        0
-------------------------------------------
Package `vanity` has been downloaded 750 times!

Django

$ vanity django -v
Django-1.1.3.tar.gz     2010-12-23    2,618
Django-1.1.4.tar.gz     2011-02-09    4,476
  Django-1.2.tar.gz     2010-05-17   15,876
Django-1.2.1.tar.gz     2010-05-24   65,120
Django-1.2.2.tar.gz     2010-09-09    2,467
Django-1.2.3.tar.gz     2010-09-11   73,984
Django-1.2.4.tar.gz     2010-12-23   49,904
Django-1.2.5.tar.gz     2011-02-09   63,977
Django-1.2.6.tar.gz     2011-09-10      427
Django-1.2.7.tar.gz     2011-09-11    6,825
  Django-1.3.tar.gz     2011-03-23  238,504
Django-1.3.1.tar.gz     2011-09-10  176,054
-------------------------------------------
Package `Django` has been downloaded 700,232 times!

Plone

$ vanity plone -v
     Plone-3.2.zip     2008-12-31    1,690
   Plone-3.2.1.zip     2009-02-04    2,466
   Plone-3.2.2.zip     2009-03-03    4,893
   Plone-3.2.3.zip     2009-06-20    2,731
   Plone-3.2a1.zip     2008-10-10      976
  Plone-3.2rc1.zip     2008-12-15      758
     Plone-3.3.zip     2009-08-19    4,611
   Plone-3.3.1.zip     2009-09-09    4,148
Plone-3.3.2.tar.gz     2009-11-03    3,043
   Plone-3.3.3.zip     2009-12-08    1,733
   Plone-3.3.4.zip     2010-01-14    4,906
   Plone-3.3.5.zip     2010-03-03   12,131
Plone-3.3.6.tar.gz     2011-07-19      787
   Plone-3.3b1.zip     2009-03-12      940
  Plone-3.3rc1.zip     2009-03-30      743
  Plone-3.3rc2.zip     2009-04-05    1,822
  Plone-3.3rc3.zip     2009-05-23    2,036
  Plone-3.3rc4.zip     2009-07-07    2,163
  Plone-3.3rc5.zip     2009-08-01    1,211
     Plone-4.0.zip     2010-08-30    3,659
   Plone-4.0.1.zip     2010-10-04    4,224
   Plone-4.0.2.zip     2010-11-22    4,022
   Plone-4.0.3.zip     2011-01-21    3,339
   Plone-4.0.4.zip     2011-03-01    2,711
   Plone-4.0.5.zip     2011-04-09    3,152
   Plone-4.0.6.zip     2011-05-22    1,469
   Plone-4.0.7.zip     2011-06-06    2,192
   Plone-4.0.8.zip     2011-07-17      509
   Plone-4.0.9.zip     2011-07-29      958
  Plone-4.0.10.zip     2011-10-12      495
   Plone-4.0a1.zip     2009-11-19      946
   Plone-4.0a2.zip     2009-12-04      921
   Plone-4.0a3.zip     2009-12-21    1,272
   Plone-4.0a4.zip     2010-02-01    1,121
   Plone-4.0a5.zip     2010-02-19      850
   Plone-4.0b1.zip     2010-03-09    1,308
   Plone-4.0b2.zip     2010-04-10    1,028
   Plone-4.0b3.zip     2010-05-04    1,722
   Plone-4.0b4.zip     2010-06-13    1,642
Plone-4.0b5.tar.gz     2010-07-08    1,995
  Plone-4.0rc1.zip     2010-08-06    1,598
     Plone-4.1.zip     2011-07-17    4,479
Plone-4.1.1.tar.gz     2011-09-21      429
Plone-4.1.2.tar.gz     2011-10-08    2,187
Plone-4.1.3.tar.gz     2011-11-29    1,883
   Plone-4.1a1.zip     2011-01-21      699
   Plone-4.1a2.zip     2011-02-11      451
   Plone-4.1a3.zip     2011-02-15      680
   Plone-4.1b1.zip     2011-03-08      958
   Plone-4.1b2.zip     2011-04-09    1,040
  Plone-4.1rc2.zip     2011-05-22      797
  Plone-4.1rc3.zip     2011-06-06    1,329
   Plone-4.2a1.zip     2011-08-10      521
   Plone-4.2a2.zip     2011-09-16      884
Plone-4.2b1.tar.gz     2011-12-06      619
------------------------------------------
Package `Plone` has been downloaded 111,877 times!

Pyramid

$ vanity pyramid -v
   pyramid-1.0.tar.gz     2011-01-31   24,055
 pyramid-1.0.1.tar.gz     2011-08-13      460
 pyramid-1.0.2.tar.gz     2011-12-15      185
 pyramid-1.0a1.tar.gz     2010-11-05    1,128
 pyramid-1.0a2.tar.gz     2010-11-09      952
 pyramid-1.0a3.tar.gz     2010-11-16      803
 pyramid-1.0a4.tar.gz     2010-11-21    1,732
 pyramid-1.0a5.tar.gz     2010-12-15      639
 pyramid-1.0a6.tar.gz     2010-12-16      834
 pyramid-1.0a7.tar.gz     2010-12-20      912
 pyramid-1.0a8.tar.gz     2010-12-27    1,233
 pyramid-1.0a9.tar.gz     2011-01-08    1,313
pyramid-1.0a10.tar.gz     2011-01-18      960
 pyramid-1.0b1.tar.gz     2011-01-22      871
 pyramid-1.0b2.tar.gz     2011-01-25    1,003
 pyramid-1.0b3.tar.gz     2011-01-28      816
   pyramid-1.1.tar.gz     2011-07-22    5,674
 pyramid-1.1.1.tar.gz     2011-08-13    1,057
 pyramid-1.1.2.tar.gz     2011-08-17    1,560
 pyramid-1.1.3.tar.gz     2011-12-15      160
 pyramid-1.1a1.tar.gz     2011-06-20    1,146
 pyramid-1.1a2.tar.gz     2011-06-23    1,003
 pyramid-1.1a3.tar.gz     2011-06-26    1,252
 pyramid-1.1a4.tar.gz     2011-07-01    1,517
 pyramid-1.1b1.tar.gz     2011-07-10      981
 pyramid-1.1b2.tar.gz     2011-07-13      844
 pyramid-1.1b3.tar.gz     2011-07-15      742
 pyramid-1.1b4.tar.gz     2011-07-18    1,094
   pyramid-1.2.tar.gz     2011-09-13    6,450
 pyramid-1.2.1.tar.gz     2011-09-28   10,357
 pyramid-1.2.2.tar.gz     2011-11-20      322
 pyramid-1.2.3.tar.gz     2011-11-21    3,078
 pyramid-1.2.4.tar.gz     2011-12-06    1,193
 pyramid-1.2.5.tar.gz     2011-12-15      555
 pyramid-1.2.6.tar.gz     2012-01-05      514
 pyramid-1.2.7.tar.gz     2012-01-20      472
 pyramid-1.2a1.tar.gz     2011-08-24      907
 pyramid-1.2a2.tar.gz     2011-08-27      696
 pyramid-1.2a3.tar.gz     2011-08-29    3,268
 pyramid-1.2a4.tar.gz     2011-09-02      593
 pyramid-1.2a5.tar.gz     2011-09-04      840
 pyramid-1.2a6.tar.gz     2011-09-07      602
 pyramid-1.2b1.tar.gz     2011-09-08      493
 pyramid-1.2b2.tar.gz     2011-09-08      700
 pyramid-1.2b3.tar.gz     2011-09-11      674
 pyramid-1.3a1.tar.gz     2011-12-09    1,264
 pyramid-1.3a2.tar.gz     2011-12-14    1,641
 pyramid-1.3a3.tar.gz     2011-12-21    2,716
 pyramid-1.3a4.tar.gz     2012-01-05      675
 pyramid-1.3a5.tar.gz     2012-01-09    2,369
 pyramid-1.3a6.tar.gz     2012-01-20    1,917
---------------------------------------------
Package `pyramid` has been downloaded 97,222 times!

Enjoy the new release.

New Plone themes are:

• HTML/CSS/JavaScript/images (Sound familiar? You don’t need to know any Plone to understand this part.)
• A set of rules that map your HTML/CSS/JavaScript/images to Plone content. (This part is Diazo-specific; and while Diazo is not part of Plone, integration is provided by a Python package called plone.app.theming.)

The Diazo rules can get complex, but it’s very easy to get your first rule done and working and then off you go. You may find this new tutorial on pythonpackages.com. Enjoy, and get busy theming Plone.

It was fun answering in 2009, so I thought I’d play again.

What’s the coolest Python application, framework or library you have discovered in 2011?

Pyramid. In early 2011 I released vanity, which later became pythonpackages.com (more or less). I used building the site as an excuse to learn Pyramid, and it was well worth it.

What new programming technique did you learn in 2011?

I learned to not reinvent the wheel, and to collaborate with others on solving hard problems (which in and of itself is hard). Long story short, I took a little bit of heat within the Plone CMS community for creating a “one off” migration script:

• http://pythonpackages.com/info/parse2plone

I’ve since learned my lesson and have been collaborating meaningfully with Dylan Jay on the more widely-supported mr.migrator and friends.

What’s the name of the open source project you contributed to the most in 2011? What did you do?

I contributed to the Plone project quite a bit (as I have been doing for years now), but I also fell in love with Mozilla (and their mission) and began working on various things, including a virtual machine to help with the development of support.mozilla.com:

• https://github.com/aclark4life/kitsune-vagrant

What was the Python blog or website you read the most in 2011?

Hacker news. I have the start-up bug.

What are the three top things you want to learn in 2012?

JavaScript, JavaScript, and JavaScript. I first heard the term 15 years ago and have been avoiding it ever since. Time to jump in.

What is the top software, application or library you wish someone would write in 2012?

I hope someone (me) writes a “secret” feature for pythonpackages.com and launches it in first quarter of 2012; and I hope folks find it useful.

I have this overwhelming desire to know how many times my favorite Python packages have been downloaded. Don’t you? If so, look no further than pythonpackages.com:

Count downloads

Where you can enter a package like Django and find out:

Count favorites

Or click on Count favorites to reveal how many times it has been favorited:

Find trash

Or even poke some good natured fun at it, for its failure to provide adequate package metadata:

Discuss packages

You can even discuss packages on pythonpackages.com:

Recent activity

But wait there is more! You can also browse the latest changelog activity from PyPi right on the site:

Package info

Lastly, if you get bored counting package downloads and favorites you can look at the actual package metadata.

Conclusion

Sound interesting? Or utterly silly, perhaps? I think pythonpackages.com is the best of both. It started off as a front end to the command line utility vanity, but has taken on a life of it’s own.

After a small run on Python reddit and Hacker News, I’m looking forward to seeing what Python Planet folks think. So please check out pythonpackages.com and let me know. You can leave comments about the site here:

• http://pythonpackages.com/about

Or open a new ticket here:

• https://bitbucket.org/pythonpackages/pythonpackages.com/issues/new

I am planning to do some work on the plone.org server and website by the end of the year, including:

• Upgrade to the latest 4.2.x series
• Switch from xdv to plone.app.theming
• Reduce the number of NGINXes running on the server by 1 (we currently have an nginx doing the xdv transform)
• Repackage the current plone.org theme as plonetheme.ploneorg
• Clean up the server
• Separate vendor package configs from buildout generated configs
• Remove archived files
• Prune tickets on dev.plone.org

I’ve done some of this work already, earlier this year:

• https://github.com/plone/Products.PloneOrg/commits/4.1-compat

Pitch

To ensure it gets done by the end of the year, I would like to add this project to my calendar as paid work. So if you are able to help out by donating some portion of the goal, I would appreciate it. Please use the chip-in below to contribute to this effort.

This just in from the production department: use Varnish. (And please forgive the heavily meme-laden approach to describing these techniques .)

Cache ALL the hosts

Our ability to use Varnish in production is no secret by now, or at least it shouldn’t be. What is often less clear is exactly how to use it. One way I like[1], is to run Varnish on your public IP port 80 and make Apache listen on your private IP port 80. Then proxy from Varnish to Apache and enjoy easy caching goodness on all your virtual hosts in Apache.

Configuration

This should require less than five minutes of down time to implement. First, configure the appropriate settings. (Well, first install Apache and Varnish if you haven’t already: `aptitude install varnish apache2` on Ubuntu Linux[0].)

Varnish

To modify the listen IP address and port, we typically edit a file like /etc/default/varnish (in Ubuntu). However you do it, configure the equivalent of the following on your system:

DAEMON_OPTS="-a 174.143.252.11:80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -s malloc,256m"

This environment variable is then passed to varnishd on the command line. Next, pass traffic to Apache like so (in /etc/varnish/default.vcl on Ubuntu):

backend default {
 .host = "127.0.0.1";
 .port = "80";
 }

Now on to Apache.

Please note that the syntax above is for Varnish 3.x and the syntax has (annoyingly) changed from 2.x to 3.x.

Apache

The Apache part is a bit simpler. You just need to change the listen port (on Ubuntu this is done in /etc/apache2/ports.conf), typically from something like:

Listen *:80

to:

Listen 127.0.0.1:80

Restart ALL the services

Now restart both services. If all goes well you shouldn’t notice any difference, except better performance, and when you make a website change and need to clear the cache[2]. For this, I rely on telnetting to the varnish port and issuing the `ban.url` command (formerly `url.purge` in 2.x):

$ telnet localhost 6082
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
200 205     
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,2.6.35.4-rscloud,x86_64,-smalloc,-smalloc,-hcritbit

Type 'help' for command list.
Type 'quit' to close CLI session.

ban.url /
200 0

Cache ALL the disks

This site has Varnish and Apache configured as described in this article. It also has disk caching in Apache enabled, thanks to Elizabeth Leddy’s article:

• http://plonechix.blogspot.com/2011/08/10-minute-caching-with-apache.html

As a result, it’s PEPPY AS THE DICKENS™ on a 512MB “slice” (Cloud server) from Rackspace Cloud. And now you know yet another “Plone secret”. Now go make your Plone sites faster, and let me know how it goes in the comments section below.

Notes

[0] Using the latest distribution, “oneric”.

[1] I first saw this technique at NASA when NASA Science was powered by Plone; I found it odd at the time but years later it makes perfect sense.

[2] Ideally you’d configure this in p.a.caching, but I’ve not been able to stomach this yet.

For almost as long as I have been involved in the Plone project, I’ve been interested in Plone’s role in the Python ecosystem. Today as I look across the current landscape, I’m proud to announce a new milestone the Plone community can take pride in. But the change didn’t happen overnight, so first let’s take a quick look back.

PyPI support in PSC

Circa 2008, Tarek Ziadé and others finished the PyPI integration branch of PloneSoftwareCenter started by Sidnei Da Silva 2 years before.

This was a big step towards the “Pythonification” of Plone, mainly because Plone packages could now be published on plone.org in the same way Python packages are published to the Python Package Index: via “python setup.py upload”. In fact if you are publishing Plone packages, it is recommended that you release to both PyPI and plone.org simultaneously. This ensures your package is visible to the most number of potential users. And you can use mkrelease to automate the process.

Collective docs at RTD

Just when you thought things couldn’t get more exciting in Python land, along came readthedocs.org (a Django Dash production, IIRC). And to join the fun in July 2011, I moved Mikko Ohtamaa’s awesome Plone Community Managed Developer Manual to the Github collective and configured the RTD service hook.

This means that whenever anyone commits a change to the developer manual, within a few minutes a new Sphinx build gets published. It was so easy to set this up, I wish I had done it sooner.

So you can that see over the years, we have been working ourselves into a frenzy of Python goodness! And last week, it got even better.

Introducing: Plone packages!

Thanks to the good folks at Cartwheel Web, makers of the fine Open Comparison service, Plone now has its very own grid comparison website! (Djangopackages.com was first, followed by pyramid.opencomparison.org.)

This is a site where folks can add packages hosted elsewhere (e.g. svn, github, pypi), vote on them, and add grid comparisons to compare similarly-featured add-ons, frameworks, and other related software. Grids are the killer feature of this site, and personally I’ve been waiting to use them to answer questions like:

Q: What’s the best blogging add-on for Plone?

A: http://plone.opencomparison.org/grids/g/weblogs/

The content is entirely user driven (TTW only) so please head over to plone.opencomparison.org, login with your github ID, and start adding packages! And while you are at it, please report any issues you find here: https://github.com/opencomparison/opencomparison/issues. Lastly, let’s all tweet a big thanks to @pydanny and @audreyr for their hard work and generosity!

Warm and fluffy history

Pillow 1.0 was released on 2010-07-31, a little over a year later came Pillow 1.7.5 which features:

• Many packaging fixes (mostly to support dependency libraries)
• Windows binaries
• Over 13K downloads

Pillow is used in Plone’s UnifiedInstaller, and I know folks from the Django community are using it.

Future creature comforts

All in all, a mild success. So what’s next? More of the same. To quote myself from a recent Stack Overflow answer:

If PIL ever does exactly what Pillow does, then the fork will die. Until that happens, we have Pillow.

Bottom line accommodations

This may never happen of course, which is part of the reason for the fork. You can’t force someone to maintain software for you. But in the open source world you can grab the bull by the horns (take the lead) and try to make things better. Even better: if your project and community are healthy and functioning properly, your success or failure will be determined by the folks in the community (as it should be). In this case, the Plone and Python communities have spoken clearly.

For the past couple weeks I’ve been working on creating a virtual machine to bootstrap a kitsune environment. Kitsune is the Django site that powers support.mozilla.com. I’ve now reached what I call the 2nd milestone.

Milestones

The milestones are as follows:

1. Get the VM running to the point where one can type ./manage.py and receive the help output (and not a traceback). This sounds trivial but there is actually a lot of work involved to get to this point. Namely, figuring out how to make Puppet execute each of the required steps successfully, together. (You would expect to be able to just define the steps in order, but those with this expectation will be disappointed. I assume Puppet has their reasons, and they are probably even good ones. )
2. Get the VM running to the point where one can open http://33.33.33.10:8000 from the host to see kitsune running. Once step #1 is done, this is actually easier than it sounds because I’m “cheating”. Test data has been imported and a syncdb has been run, but I’m using supervisor to manage the runserver process (for now).
3. Get the VM running like it does in production. This will involve configuring Apache and mod_wsgi as well as resolving any issues that remain with the app. I’ll rely on the kitsune team to help with this, as I’m still learning the app. This is the “exciting” part for me because I get to learn something new. While Vagrant and Puppet are also new to me, I consider these technologies part of my “past life” (as a system administrator) and Django sites part of my “future life” (as a web developer).

Now about the technologies.

Vagrant

I had heard of Vagrant before, but never tried it. I am now sorry I waited so long because the “cool factor” is very high. It requires that Virtualbox be installed, which I also danced around for too long before committing (being a former Parallels user).

On OS X Lion[1], installing Vagrant is simply a matter of:

$ gem install vagrant

Once you have `vagrant` installed you can do:

$ vagrant init

inside some revision-controlled directory and you have the beginnings of a virtual machine you can share with the masses. This is how kitsune-vagrant was born. Hopefully this shared virtual machine will eventually make some new developer’s life much easier.

We now arrive at a fork in the road; though Vagrant makes it easy to follow both paths: Chef or Puppet (it supports both). I don’t recall what made me choose Puppet over Chef, but it might have been that the Socorro folks were using it already.

Once you decide on Puppet (and assuming you do), it’s pretty easy to figure out that your next move is to create a manifest file for Puppet to apply[2].

Puppet

My knowledge of Puppet is currently quite limited. Specifically, I only know how to create a manifest file. (Vagrant does the rest!) I imagine there is much more to Puppet, especially with regard to doing actual configuration management on production servers. But I have not explored any of that yet.

However, I did learn quite a bit about Puppet just from writing the manifest. The first most important thing I learned is this: Puppet is in charge. It does things the way it wants to and you need to follow its rules. The first and biggest challenge is to achieve a linear execution of tasks.

You cannot write rules in order and hope for the best. This will fail spectacularly when something executes before something else was supposed to. The way around this is via `require =>` statements.

A grep through kitsune.pp reveals:

    require => Exec['git_clone'],
    require => Exec['db_sync'],
    require => Exec['packages_upgrade'],
    require => Exec['packages_update'],
    require => Package[$packages_native],
    require => Exec['git_clone'],
    require => Exec['chown_kitsune'],
    require => Exec['packages_compiled'],
    require => Exec['packages_vendor'],
    require => Exec['db_create'],
    require => Exec['db_import'],
    require => file['/etc/supervisor/supervisord.conf'],
    require => Exec['supervisor_stop'],

This roughly translates to the following workflow logic:

• Ensure that `aptitude -y update; aptitude -y upgrade` have been run before you try to install the list of packages we require.
• Ensure the list of packages we require is installed before we checkout the code.
• Ensure the code has been checked out (and pip install / git submodule have been run) before you try to syncdb and run the application.

There is a bit more to it, but with that knowledge you should be able to read and understand kitsune.pp in full. I learned most of the remaining required puppeteering from this site: http://www.puppetcookbook.com/.

Mozilla

Oh my! This Mozilla work is a ton of fun[3]; I attribute this in part due to the structure of their organization: I was invited immediately to collaborate in IRC with the kitsune team and as a result, we all have something to show for it[4].

Next I will be working on the 3rd milestone! Hope to finish by the end of this week.

Notes

[1] This did not work on Snow Leopard, because `gem` is too old. However if you `brew install ruby` and try again, it should work.

[2] I didn’t bother to investigate Chef, but I am curious about it.

[3] And I hope this is only the beginning.

[4] I hope to get a Mozilla gig but even if I don’t, being able to do this type of work is very rewarding (which is why you will often hear people in open source say that to get paid for the type of work they do is a dream come true ).

I recently began doing some volunteer work for Mozilla[1], working on a virtual machine setup to make kitsune development easier (kitsune is the code name for the Django site that powers support.mozilla.com).

Git submodules

In doing so, I came across an interesting command from their installation docs:

$ git submodule update --init --recursive

I can recall some vague rumblings about git submodules prior to this incident, but nothing I’d call “familiarity”. So, I shrugged it off and went about the business of creating the VM (and resisting the urge to use zc.buildout to do it):

• On day 1, I created a VirtualBox VM using the latest Ubuntu Server and was able to assemble and run the application by following the instructions.
• On day 2, I began to “vagrantize” the process. Here I ran into a bit of trouble with the git-submodule command[2]. This led me to seek alternative methods to install the various Python packages it was trying to install (when stuck on a problem I often like to pursue the alternatives immediately, so I have them if I need them.)

Zamboni

Then, in the Mozilla IRC channel #sumodev (support mozilla) some nice Mozillian (willkg) pointed me to this gem:

• http://mozweb.readthedocs.org/en/latest/packaging.html

Which in turn led me to the following two links:

• http://jbalogh.github.com/zamboni/topics/packages/
• http://playdoh.readthedocs.org/en/latest/packages.html#packages

Again, faint rumblings… this time about zamboni (not THAT Zamboni). I know I’ve heard of it, but I wouldn’t call myself familiar with it. So, I innocently read the following:

Python projects can incur a number of dependencies. pip can be handy, but we’ve had better luck with distributing a vendor library.

At which point I immediately thought to myself:

Yeah… I hear that.

Followed a few seconds later by

Wait… what?!?

Playdoh

Some time/research later[3], I (re)discovered that zamboni is the codename for addons.mozilla.org[4]. And Playdoh is the code name for Mozilla’s base Django project setup. If you aren’t familiar with Playdoh, please do give it a whirl[5].

PyPI

While all of this is very, very interesting to me, I am primarily a “systems and processes” guy; and what ultimately stuck with me after two days of Mozilla-ing is the following blurb from the Playdoh packaging documentation:

The /vendor library is supposed to contain all packages and repositories. It enables the project to be deployed as one package onto many machines, without relying on PyPI-based installations on each target machine.

“Nooooooooooooooo”, I am now saying to myself over and over. “Without relying on PyPI-based installations on each target machine.” Another “noooooooooooooooo!” I certainly don’t fault Mozilla for taking this approach, but it makes me sad that large organizations like Mozilla are passing over PyPI in favor of alternative methods of distributing Python software.

Let us all now hang our heads, for a moment of pause and reflection.

[a minute passes]

The future

I can’t speak for anyone else, but I would certainly like to see this change in the future. I would LOVE to see PyPI become a place that Mozilla felt confident it could use to deploy Python software. And this is something I’d love to work on for Mozilla, if given the opportunity[6].

Great for Python == great for Mozilla?

It’s obvious what’s in it for Python, but what’s in for Mozilla?

Simple.

I happen to share Mozilla’s vision for an open web and open source in general. And it’s great to see them embracing & using Python for their web projects! Without a doubt,  they are interested in giving back to the Python community (e.g. via Playdoh and the Django community, in this case.) So I suspect they’d be open to helping the Python community fix a long standing issue: the stability and reliability of the Python Package Index. It would certainly benefit them in the long run to simplify their build process to the point where git-submodule was no longer needed[7].

Notes

[1] I am actively courting Mozilla in hopes of landing a gig by the end of the year. So all you Mozillians who know me personally, please put in a good word! And all you Mozillians I have not met yet: nice to meet you!

[2] The problem turned out to be git-submodule failing to run because things like: grep and sed were missing from the PATH. Easily fixed by modifying the puppet configuration, but not easily discovered because git-submodule itself returned zero! Some guy on #puppet was very helpful in getting me to print out debug info.

[3] More help from friendly Mozillians in #webdev:

11:13 < groovecoder> aclark: yeah, zamboni is amo
11:13 < kumar> playdoh was extracted from zamboni and other apps
11:13 < kumar> but zamboni itself does not eat the playdoh dog food, actually
11:15 < kumar> aclark also, in case you’re not steeped in our initialisms, amo is addons.mozilla.org

[4] There is a great presentation about it here: http://www.slideshare.net/andymckay/anatomy-of-a-large-django-site-7590098.)

[5] More from kumar (emphasis is my own):

11:25 < kumar> Playdoh is starting to stabilize so it would be good to see some use of it outside Mozilla; this would probably
help us catch Mozilla-specific things that need extraction

[6] LARGE HINT

[7] Again, not that there is anything wrong with what Mozilla is doing here. As a systems guy, I just happen to gravitate toward simplifying processes by eliminating steps.