fold distutils back into Python distro?
As I understand it, numpy (or maybe it's scipy) has its own fork of distutils. What would it take to fold it back into the main distribution? Skip
skip@pobox.com wrote:
As I understand it, numpy (or maybe it's scipy) has its own fork of distutils. What would it take to fold it back into the main distribution?
I guess a PEP that nobody has been willing to write. I suspect that not all of the numpy extensions are going to be seen as necessary by the Python people, and I don't know of anybody that's been willing to try and wrestle with that legwork. And just for clarification. As far as I understand it, it's not technically a fork of distutils. It is based on distutils but just extends it in many ways (i.e. new subclasses that extend from the Distutils classes). Pearu is the expert on it, however. -Travis
Travis> And just for clarification. As far as I understand it, it's not Travis> technically a fork of distutils. It is based on distutils but Travis> just extends it in many ways (i.e. new subclasses that extend Travis> from the Distutils classes). Ah, okay. That's different. I was thinking it was a fork. Skip
skip@pobox.com wrote:
As I understand it, numpy (or maybe it's scipy) has its own fork of distutils. What would it take to fold it back into the main distribution?
numpy.distutils (nee scipy_distutils) is not really a fork. It's just a set of extensions to distutils. One of the primary features is handling extensions with FORTRAN code. If you can convince Guido that standard distutils ought to handle FORTRAN, then we might have a deal. Some of the other features might be rolled into the standard library, but probably not on the 2.5 time frame. The useful ones might be the system_info stuff (which you have recently become far too familiar with :-)), the build_src capabilities, colored output, and the Configuration object. -- Robert Kern robert.kern@gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Robert> numpy.distutils (nee scipy_distutils) is not really a fork. It's Robert> just a set of extensions to distutils. One of the primary Robert> features is handling extensions with FORTRAN code. If you can Robert> convince Guido that standard distutils ought to handle FORTRAN, Robert> then we might have a deal. I see no reason why that wouldn't be possible in principle. After all, the bdist_* stuff keeps growing to handle a number of different package formats. Robert> Some of the other features might be rolled into the standard Robert> library, but probably not on the 2.5 time frame. The useful ones Robert> might be the system_info stuff (which you have recently become Robert> far too familiar with :-)), the build_src capabilities, colored Robert> output, and the Configuration object. Any idea if patches for each could be created fairly easily for each of these? Skip
On Wed, 01 Mar 2006 18:21:41 -0600 Robert Kern <robert.kern@gmail.com> wrote:
Some of the other features might be rolled into the standard library, but probably not on the 2.5 time frame. The useful ones might be the system_info stuff (which you have recently become far too familiar with :-)), the build_src capabilities, colored output, and the Configuration object.
IMO, the colored output should be an optional feature. My emacs buffers do not understand it and the only way to disable it is modifying the source as far as I remember. Gerard
participants (4)
-
Gerard Vermeulen -
Robert Kern -
skip＠pobox.com -
Travis Oliphant