A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2001-April/014201.html below:

[Python-Dev] compileall.py and make install

[Python-Dev] compileall.py and make installGuido 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/)



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4