#10 closed defect (fixed)

clean up after yourself when told to "make clean"

Reported by: zooko Owned by: zooko
Priority: minor Milestone: 0.6.1
Component: packaging Version: 0.6.0
Keywords: Cc:
Launchpad Bug:

Description

make "./setup.py clean --all" really clean up properly

Change History (17)

comment:1 Changed at 2007-04-27T23:45:18Z by zooko

I'd like to add a test to be executed by the buildslave that does "make ; make clean" and then asserts that "darcs whatsnew -s -l" shows no new files.

comment:2 Changed at 2007-04-28T19:15:20Z by warner

  • Component changed from component1 to unknown
  • Owner changed from somebody to nobody

comment:3 Changed at 2007-04-30T05:32:36Z by zooko

  • Owner changed from nobody to zooko
  • Priority changed from major to minor
  • Status changed from new to assigned

comment:4 Changed at 2007-05-02T02:51:41Z by zooko

#6 merged into here

comment:5 Changed at 2007-05-06T20:37:32Z by zooko

  • Summary changed from clean up after yourself to clean up after yourself when told to "make clean"

comment:6 Changed at 2007-05-07T00:30:01Z by zooko

  • Component changed from unknown to packaging

comment:7 Changed at 2007-05-24T00:35:36Z by warner

I'll work on this. I noticed that 'make; darcs whatsnew -s -l' shows no new files: i.e., our .darcs-boringfile is doing a great job of ignoring generated files, which makes darcs less-than-useful to detect generated files :-).

I think that I'll build two tests. One will verify that .darcs-boringfile is doing its job, and will pass if 'make; darcs whatsnew -s -l' says 'No changes!'. The second will verify that we clean up after ourselves, and will be something like:

find . -ls |sort >allfiles.tmp.old
make
make clean
find . -ls |grep -v allfiles.tmp |sort >allfiles.tmp.new
diff allfiles.tmp.old allfiles.tmp.new

and see if there are any differences.

comment:8 Changed at 2007-05-24T01:17:42Z by warner

I've added these tests, in 319516a5a212cdf3, 13e2af80339eceeb, and 8b9d7d6306137b86. The test-darcs-boringfile test should be passing now, but the test-clean check is failing. The problems fall into the following categories:

  • src/allmydata/version.py
  • build-in-place .pyc files for foolscap
  • src/zfec/ez_setup.pyc
  • src/zfec/zfec.egg-info

comment:9 Changed at 2007-05-30T02:08:25Z by warner

I spent a few minutes trying to figure out why foolscap has .pyc files in place, with no luck. 'make build-foolscap' is sufficient to cause src/foolscap/foolscap/pb.pyc to be created. We're not doing a 'setup.py build -i' anywhere, and I can't find anywhere that might be adding src/foolscap to PYTHONPATH and then importing foolscap modules. I see two copies of pb.pyc created: the expected one in instdir/lib/foolscap/pb.pyc and the unwanted one in src/foolscap/foolscap/pb.pyc. The instdir one is easy to clean up, but the src/foolscap one isn't (I don't want to add a 'find *.pyc -exec rm' statement to the clean target, since I'd much prefer to put all the generated files in one place rather than go traipsing through source directories looking for them).

src/allmydata/version.py is generated by all build targets, and should probably be deleted by the clean target. I have no idea what zfec and eggs are up to.

comment:10 Changed at 2007-07-26T03:33:04Z by zooko

  • Milestone set to 0.5.0

Note to self: I really want the buildbot status to be all green when we release v0.5.

This isn't a "blocker" -- it isn't that important -- but I'm putting it in the v0.5 milestone to remind myself when I look at this link tomorrow:

http://allmydata.org/trac/tahoe/query?status=new&status=assigned&status=reopened&groupdesc=1&group=priority&component=code&milestone=0.5.0&order=priority

comment:11 Changed at 2007-07-26T21:26:56Z by zooko

I have asked for help from the setuptools experts at the distutils-sig mailing list.

My current hypothesis is that setuptools ought to be amended to *not* product the .egg-info directory when the --single-version-externally-managed flag is present.

comment:12 Changed at 2007-08-16T21:53:48Z by zooko

  • Milestone changed from 0.5.0 to 0.6.0

bumping this to v0.6

comment:13 Changed at 2007-08-18T00:06:57Z by warner

With 8088044bf3a7dc5d, our 'make clean' target restores the tree to its original state, and the buildbot 'clean' builder is now green. This uses clean-zfec and clean-setuptools targets that explicitly delete all of the random .pyc and egg.info and setuptools.egg files that are created during their building, which may not be as satisfactory a solution as changing the setup.py files to do this in the 'setup.py clean' target.. I'll leave that decision up to zooko.

comment:14 Changed at 2007-09-19T23:07:20Z by zooko

  • Milestone changed from 0.6.0 to 0.6.1

comment:15 Changed at 2007-10-01T22:13:46Z by zooko

  • Version set to 0.6.0

comment:16 Changed at 2007-10-11T22:42:56Z by warner

are we happy with how this works now?

comment:17 Changed at 2007-10-13T20:14:01Z by zooko

  • Resolution set to fixed
  • Status changed from assigned to closed

Yep! It is all good. Now, for the record, we no longer have clean-zfec and clean-setuptools targets, but we do explicitly delete random .pyc and such, as per this excerpt from the Makefile:

clean:
	rm -rf build _trial_temp _test_memory .checked-deps .built
	rm -f debian
	rm -f `find src/allmydata -name '*.so' -or -name '*.pyc'`
	rm -rf tahoe_deps.egg-info allmydata_tahoe.egg-info
	rm -rf support dist
	rm -rf setuptools*.egg *.pyc
Note: See TracTickets for help on using tickets.