Repository navigation
More setup.py/version fixes - #32
Conversation
…tead use astropy.version.release.
…ny setuptools/distribute-specific machinery to determine whether or not to update the git revision at import-time. Instead it just does so whenever astropy is being imported from withing a git working dir.
|
On Mon, Oct 24, 2011 at 3:31 PM, Erik Bray <
This flag is used to turn on and off debugging asserts (range checking and |
|
In that case we could add a debug variable and a I'll go ahead and add that here. |
There was a problem hiding this comment.
I wonder if instead of using show_warning, we should send the warning to distutils.log.warn?
There was a problem hiding this comment.
I seem to recall thinking that at one point to, but decided against it for reasons I can no longer recall.
But even so, if I used log.warn these warnings will still always show unless the default log level is set higher than 'warn'. Maybe that's not such a bad thing. But as I've learned recently with PyFITS too many "warnings" scare users.
|
+1 for the idea of a debug option. Perhaps we should even call it I'm also glad for getting rid of the distribution stuff in version.py - it was causing a variety of strange problems for me. |
|
Right, like I said in my e-mail the approach I was using isn't even reliable anymore (It used to be, but apparently hasn't been for a long time). So better to dispense with it. As for the --debug option, the build and build_ext commands already have a Another nice advantage of my patch (which adds a custom build command) is that it rebuilds the C code if the "debug" status changes from the last build. The normal build command doesn't do this (you have to manually rm -rf build/) since it has no way of knowing what type of build was last performed. |
|
@iguananaut: That sounds like it perfectly meets astropy.wcs' needs. Thanks. |
…sing the `--debug` option to `./setup.py build` (note: this is not supported by `./setup.py install` install, so you must manually run `build` to create a debug build). If `./setup.py build` is run without `--debug` then the debug flag is set to `False`. If the debug value changes from the previous build, a rebuild of all C extensions is forced. There are at least two advantages to having `debug` in version.py. The first is informational: Whether or not the package was built with debug enabled is frozen with the source code. The other advantage is that the flag becomes globally available to modules that need to configure C extensions, and it could even be used by pure Python code, for example, to enable debug logging globally. This patch went through several iterations before I was happy with it. The Cython changes are mostly incidental at this point, though in an earlier version of the patch they were more necessary. This is because the `build` and `build_ext` commands were being subclassed. However, I eventually realized that in order for that approach to work consistently it would also be necessary to subclass all of the other `build_` commands. And the more you start overriding things in distutils the further you start going down the `numpy.distutils` path, which is a direction best avoided. This version of the patch still uses the distutils machinery to get the value of the --debug option. This has the advantage that it can also take the debug option from one's setup.cfg file. For example, adding [build] debug = True to setup.cfg during development ensures that debug mode is always turned on, for example.
Adjusts setup.py version version freezing to be more stable and additional associated clarification in setup.py
Two bug fixes to pull request #32
Adjusts setup.py version version freezing to be more stable and additional associated clarification in setup.py
Two bug fixes to pull request astropy#32
3 participants
These are two fixes that resulted from an exchange I had with @eteq earlier.
The first is the get rid of a
BUILDvariable in setup.py that was an artifact of PyWCS's setup.py. Instead it usesastropy.version.releasewhich has in effect the same semantics (theoretically one might want to do a 'release' build while still under development, but in that remote case the developer may manually remove 'dev' from the version).The second is another fix to the version.py template. It's now much simpler than before and does not rely on any obscure (and unreliable) machinery in pkg_resources. Instead it just checks if astropy is being imported from within a git working copy, and if so it updates the version string if necessary. If astropy is not being imported from within a git working dir then the version is left "frozen".