Changes between Initial Version and Version 1 of Ticket #21566, comment 4


Ignore:
Timestamp:
09/23/16 13:38:43 (3 years ago)
Author:
embray
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #21566, comment 4

    initial v1  
    1 I wonder if this work might not also benefit from adopting portions of [https://github.com/astropy/astropy-helpers/tree/master/astropy_helpers astropy-helpers] into Sage's build tools.  I don't think it would necessarily be appropriate to use directly--although there's nothing very "astropy" specific in astropy-helpers, a lot of it does assume one is using the astropy project template, or something close to it.  But large swaths of it are very generic, and I put a lot of work into developing tools for build sanity of large Python projects.
    2 
    3 Some key features that I think might benefit sage include:
    4 
    5 * per-subpackage `setup_package.py` modules, which can contain any number of a [http://docs.astropy.org/en/stable/development/building.html#customizing-setup-build-for-subpackages (mostly) well-documented] hooks for building compiled modules in that sub-package.  This provides a clear and explicit alternative to a monolithic module_list.py (see the discussion [https://github.com/cython/cython/pull/466#issuecomment-249185195 here]), and would also make it easier to break off some of Sage's subpackages into standalone packages should the time ever come for that.
    6 * one of the less-well-documented features is also that `setup_package.py` can contain hooks for setup.py commands.  For example, if a module contains some generated code (a la `sage_setup.autogen`), it can include a `pre_build_ext` hook to make sure the generated code is up to date before running the `./setup.py build_ext` command (either explicitly, or implicitly as a sub-command).  This makes it relatively easy for individual submodules to put hooks into the build process without having to write complicated command subclasses cluttered with subpackage-specific crud.
    7 * smarter handling of Cython modules--for example, when creating a source tarball it will make sure all Cython modules have been Cythonized, and it will include the resulting C/C++ sources in the source tarball.  This ensures that the user does not need Cython to be installed in order to build from source (which is good, because even if they do have Cython it will often be the wrong version--and in Sage's case missing important patches as well).
    8 
    9 Those are the main ones for now but I could probably think of more.
     1(Sorry, the comment that was here previously was meant to go on #21507 -- I have too many tabs open)