Debian's python produces a different finalizers.png

Fine on sid too (repeatably)

And I was wondering recently why I *didn't* see the gc.garbage list in the finalizers.png graph on my machine (Ubuntu, various Python versions).

I've got a Debian box here (don't even remember the version), I'll turn it on and try to reproduce.

This is not a serious issue; perhaps the test should be fixed to accept either number of nodes (using an ellipsis instead of the number).

I can't reproduce this with Python 2.5 on Debian lenny.

Hi Marius (2010.12.08_15:31:06_+0200)
> I've got a Debian box here (don't even remember the version), I'll turn
> it on and try to reproduce.

I can't replicate it in a clean chroot with the same packages installed
or another machine. I can't see what's causing this difference and why.
(I'm not about to read Python's garbage collector :P )

> This is not a serious issue; perhaps the test should be fixed to accept
> either number of nodes (using an ellipsis instead of the number).

That sounds sensible enough.

BTW, the test doesn't fail (return non-zero) if it fails, can you please
use the TestResult you get back from TextTestRunner to exit()
appropriately?

SR

--
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127

'make test' *should* return non-zero if this happens, and I'm pretty sure it does.

'make images' didn't bother, because it's main purpose is to regenerate the images that accompany the documentation, and it's intended to be run by the maintainer (i.e. myself) manually, with careful manual inspection of the images to see that they make sense. On second thought, a command like 'make clean images docs' should abort if a syntax error or whatnot prevents the images from being generated at all, so I've change the build-images in setup.py to sys.exit(1) if the doctests fail.

I don't know what to do about the main issue, though. I'd love to be able to reproduce it; I was going to try schroot, but now that you say you can't reproduce it in a chroot, I'm not sure anymore. I tried to get Ubuntu's python to put the uncollectable object into gc.garbage, without success.

I'll try a different approach.

I managed to convince Python to put this object into gc.garbage on my machine, with all Python versions. Not sure why my attempt to do the same failed earlier; I used the same approach again...

> 'make test' *should* return non-zero if this happens, and I'm pretty
> sure it does.

Aah, right it does. I'd ignored that because I was running make images,
anyway.

> On second thought, a command like 'make clean images docs' should
> abort if a syntax error or whatnot prevents the images from being
> generated at all, so I've change the build-images in setup.py to
> sys.exit(1) if the doctests fail.

Thanks, it's nice for me to have the build fail if anything goes wrong.

FWIW I don't think you should be running 'make images' during a build. The images in the released tarball (or the bazaar branch revision tagged as a release) will be up-to-date.

I'm generally against committing generated files into a source repository, but in this case the images are documenting expected output, as an aid for manual testing, so I want known good versions of them to be present in the repo.

If you want to generate HTML docs for /usr/share/doc/, 'make clean html' will suffice -- it'll copy the png images into _build/html/.

I've just released 1.5.1 with this fix.

> FWIW I don't think you should be running 'make images' during a build.

General Debian policy is to rebuild all generated files from source
during build. This is partially to show that it can be done.

I'm happy enough not to, if you are concerned about it.

> If you want to generate HTML docs for /usr/share/doc/, 'make clean html'
> will suffice -- it'll copy the png images into _build/html/.

Yes, I'm using make docs:

http://svn.debian.org/viewsvn/python-modules/packages/objgraph/trunk/debian/rules?revision=15047&view=markup

I'm -0 for rebuilding them: this would result in the figures in /usr/share being different from the ones on the project website for the same version. 'make test' is sufficient to show the generation will work -- it performs the same thing as 'make images', but in a temporary directory that's cleaned up at the end.

I'd change my opinion to +1 if the images didn't change after every rebuild. This seems non-trivial; I'd probably need a registry of custom functions to replace repr() in order to avoid memory addresses of things like DocTestRunner instances appearing in the rendered image. Or I could hardcode them all with a series of ifs in my short_repr, but I already feel like I have enough special saces there. Hm. This bears more thinking about.

(I assume you're familiar with the numerical expressions of approval used in the Python community: -0 means neutrality, with a slight bias against the change; +1 means agreement.)