Present were Tom, David, Simon, Sami, Peter, Jacob and myself.
Simon talked briefly about his project to "reimplement" the git command line tools on Windows. He had experience of particular operations being very slow with the normal git Windows tools, so as an experiment took libgit2 and started wrapping it in Cython so he could rewrite the particular git tool in Python, to see if libgit2 was faster. Although I think he said the result (for that particular tool) wasn't particularly promising, he may continue to write the git command line tools in Python (matching the API of the originals), which I think is an interesting idea (and would remove some of the odd dependencies of the "traditional" git command line tools).
David Cournapeau of Enthought then did the talk "Towards better dependency handling: Using SAT solvers for greater good" that he had volunteered.
David gave a talk on bento (
http://cournape.github.com/Bento/) a while back, an improved Python packaging solution. This got him interested in how to handle the dependencies between installables.
easy_install allows specifying naive dependencies, at the level of "the latest version" of a particular package.
pip tends to pin particular versions of the packages it needs.
Both of those approaches are problematical (and, I'd say, ultimately unhelpful).
He wants a solution that supports promises, conflicts and obsoletes - as Debian's apt does, but in a perfect world less complex. The operations that are needed are install, update and remove.
This is the sort of dependency where choices are to be made between possible options, which traditionally involve lots of tree traversal and backtracking.
In particular, one can end up with multiple viable options (update this package and install that one, or replace this package entirely and install that other one). The aim is to try to keep installed packages, and reduce the number of items that need downloading. SAT techniques can solve problems that backtracking/network based solutions cannot realistically solve.
PHP Composer was inspired by lib solver, which is used by OpenSUSE in its package manager.
We then carried on into a general discussion of packaging and its problems.
Also, before we ended, Tom talked a little about Fedora system tap, which has Python extensions to give dumps of Python whilst its running.
Linux "perf" tool was discussed briefly, which is a userspace tool using the Linux kernel that uses the kernel "perf_events" interface to report on how an application is behaving. We wondered if one day it too might grow to recognise Python.
Someone (I didn't write down who) was enthusiatic about the valgrind tool "massif", which looks at a loop that is leaking memory and gives backtrace of where the problem is.
And then most people went on to the pub, but I had to go home and so missed it.
Tibs