My next major initiative for Hep is building some native install
packages. I want to have binary installs for Debian, Windows, and OS
X, at a minimum – Debian and OS X because that’s what the majority of
Python/Twisted/RSS/Atom/Weblog developers seem to be using, and Windows
because, well, it’s Windows. (Users of RPM-based Linux distros: I care
about you, but I have to draw the line somewhere, and all this
packaging work is hard. More on that in a minute).
I’m focusing on packaging because I want more people to try out Hep,
and right now it’s pretty hard to get running if you’re not already
familiar with Twisted’s mktap, twistd, and friends. I want it to be
possible to ‘apt-get install hep’, (or run an installer) and have a
working Hep installation.
At this point I should mention that the Windows installer for Hep 0.6
was broken (thanks to John Kastler
for bringing this to my attention), so I’ve taken it down for now.
I’ll have a new installer up soon; for now, savvy Windows Python users
can install the tarball.
Anyway, I’m working on putting together these native packages, and it’s
turning out to be a lot of work. I suppose this shouldn’t be a
suprise; Fred Brooks
said that developing a packaged, documented software system was up
to 9 times as much work as simply creating software that worked for
your own purposes. That’s certainly true in this case.
Here’s the minimum you need to know to develop a cross-platform
application in Python:
- Python
And here’s the minimum you need to know to distribute native standalone
packages for Debian, OS X, and Windows:
- Python Distutils
- make
- how to make a
Debian Package
to set up an Apt repository
X Package Maker- Py2Exe
- InnoSetup
That second list represents something like a whole day’s worth of
reading just to get started, followed by actually figuring out how to
use the tools in question, each of which includes at least one special
file format/configuration language. So I’m a little overwhelmed at the
moment. But I’ve begun the process. First up: debs. Stay tuned.
I’m really looking forward to an OS X package (or Fink install).
As you correctly state, getting all the dependencies in place by hand when you are unfamiliar is a real turn off.
I’m happy to give feedback on the install on some fairly clean machines (definitely had no other Python stuff installed before):
OS X (10.3), Debian, and a Win2k Server.
Also wondered if you are in touch with Marc Liyanage, the package master of OS X (http://www.entropy.ch/)?
I’ve done this sort of stuff before and I can vouch for how underappreciated release engineering is, trying to go from an assemble the bits release to a fully fledged standalone app is a huge job.
If you want to simplify your life a small amount on the mac you could stick with fink only at first (though you’ll get many more people with a nice standalone app). The fink info files are easy to edit, and if stuff is distutil’d properly, python stuff is a breeze to install.
If you want good examples of packaging an server style application I’d look at Plone (http://plone.org/) on the mac. The plone folks have done a great job of packaging up plone with a proper startup script and package management. Upgrading plone is fairly easy too. On the windows side they deliver a nice control panel too, and hook into windows services.
For more on python mac app bundle generation, look at Bob Ippolito’s work, http://www.pycs.net/bob/weblog/ , he’s aiming for py2exe style .app generation. The pyobjc stuff has some relevant info too.
py2exe *should* take care of the windows side fairly easily, then use nsis (http://nsis.sourceforge.net/) to generate a nice windows installer (nsis is great, faster, more powerful and nicer to develop with than most of the commercial installers).
Wow, great links, guys. Thank you!
metafeather, I’ll definitely be looking for some testers once I get my packages together. Thanks for volunteering!
Michael, any thoughts on NSIS vs. InnoSetup?