Automatically deleting pyc files when corresponding py is moved (Mercurial)

Question

(I foresaw this problem might happen 3 months ago, and was told to be diligent to avoid it. Yesterday, I was bitten by it, hard, and now that it has cost me real money, I am keen to fix it.)

If I move one of my Python source files into another directory, I need to remember to tell Mercurial that it moved (hg move).

When I deploy the new software to my server with Mercurial, it carefully deletes the old Python file and creates it in the new directory.

However, Mercurial is unaware of the pyc file in the same directory, and leaves it behind. The old pyc is used preferentially over new python file by other modules in the same directory.

What ensues is NOT hilarity.

How can I persuade Mercurial to automatically delete my old pyc file when I move the python file? Is there another better practice? Trying to remember to delete the pyc file from all the Mercurial repositories isn't working.

Answer 1

1. Do not store .pyc files in the repository.
2. Automatize .pyc delete with: find . -name '*.pyc' -delete
3. While develop use -B argument in Python.

Answer 2

How about using an update hook on the server side? Put this in the repository's .hg directory's hgrc file:

[hooks]
update = find . -name '*.pyc' | xargs rm

That will delete all .pyc files whenever you update on the server. If you're worried about the cost of rebuilding all the .pyc files you could always get just a little more clever in the hook and delete only the .pyc's for which there is no .py, but that's probably overkill.

Answer 3

You need:

1) A real deployment infrastructure, even if it's just a shell script, which does everything. Cloning/checking out an updated copy from source control is not a deployment strategy.

2) Any deployment system should completely clean the directory structure. My usual preference is that each deployment happens to a new directory named with a date+timestamp, and a symlink (with a name like "current") is updated to point to the new directory. This gives you breadcrumbs on each server should something go wrong.

3) To fix whatever is running the Python code. New .py source files should always take precedence over cached .pyc files. If that is not the behavior you are seeing, it is a bug, and you need to figure out why it is happening.