One nice thing about using Python is the simple and easy way to get libraries and other packages quickly and easily using tools like pypi and pip. However, when deploying I prefer OS packages (typically RPMs since I've worked at RHEL/Fedora using shops). Sometimes the libraries I need are not packaged by upstream and I end up building them myself.
None of that bugs me. What I what I wish was that more OSS projects, especially some of the smaller libs, would actually release occasionally. Instead I have to get a copy out of source control, which often has no release information. This makes me queasy because I have a hard time telling if the most recent versions are stable. Even if you don't want to make tarballs, at least periodically tag your releases in a way that makes us downstream users feel some confidence that your code isn't halfway in the middle of a refactoring or something.
If it's a "mature" code base, one that changes rarely, stick a release tag on there once a year or something. I'm going to end up testing this stuff for my own purposes, but a release tag at least makes me feel that I'm not going to end up wasting too much of my time on software left in the lurch. So far some of the worst offenders are on the dev sites like bitbucket and github. I don't know if my sample size is just too small or I have bad luck, but I have a guess that in the ye olden days people had to create a tarball just to get hold of the code, but these newer sites/tools make it easy for people to skip that step, and then forget completely about doing a release at all.
I don't actually think anyone is going to listen to me, and I'm going to have to keep building packages that have strings like "20101114git83848383f3892" or "20110109hgf110ac096f19" in them. But hope springs eternal :-).
© Copyright 2009-2011 John Mulligan
Every blog page or article on this site is available under the CC-BY-SA license unless otherwise noted.