[Python-Dev] compileall.py and make install
Guido van Rossum
guido@digicool.com
Fri, 13 Apr 2001 14:45:51 -0500
> There are two related problems that I'd like to fix for the release
> candidate. One is that compileall.py basically ignores compiler
> errors. It's clear that the code intends to return with a non-zero
> exit status if there are compilation errors, but it doesn't do that
> currently.
>
> If I fix just this problem, make install will start to fail because
> there are six files in the test directory that contain intentional
> SyntaxErrors; in one case, it's necessary that the SyntaxError be
> raised through import.
>
> I'd like to fix compileall.py and add an optional argument that tells
> it to skip files that match a regular expression. Then I'll rename
> all the offending files so that they are named badsyntax_XXX and fix
> the Makefile so that it installs them but does not compile them.
>
> This is going to cause two problems for developers. First, you'll
> need to manually delete the files with the old names from the install
> lib directory. (I'll rename nocaret.py to badsyntax_nocaret.py, but,
> if you've already done an install, you'll also have a nocaret.py in
> the lib directory.)
>
> The compileall script also traverses into site-packages. If you have
> compilation errors in code that you've installed into site-packages,
> then make install will fail.
>
> I'm not sure what to do about this. During development, at least, it
> is probably helpful for make install to walk into site-packages and
> fail if the new version of Python breaks existing code. On the other
> hand, it could be a big pain that you can't install Python just
> because you previously installed a buggy Python library. Of course,
> you could just remove the broken code.
>
> I think it's a net gain to make these changes. Is anyone more
> concerned that me about the possible breakage?
-1 for getting this in the 2.1 release. +1 for fixing this soon
after. I'm beginning to see the point of branching off for releases!
I'm not sure what advantage there is to compileall.py returning a
non-zero exit code, and I clearly see the risk of doing it so close to
the release. I have about three hours to send the release candidate
out, I want to do some more testing, *and* I want to have the night
off... :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)