I've been trying to get the setup.py scripts in the Numeric distribution to build binary distributions. I have tried several things but what always ends up being a problem is the current Numeric organization, specifically LALITE and RANLIB. They just don't fit well with the distutils paradigm. If they were packaged as part of the Numeric core but were a build-time option, I think that I could get things to work much more easily. The configuration part of distutils is still a bit imature but overcomming that would just require a slightly more involved setup.py. I don't want to go ahead if there is no chance of it being accepted. Tony
On Sun, 21 Jan 2001, John J. Lee wrote:
I'm not sure what you mean. Even './setup_all.py build' doen't work for FFT, LALITE, RANLIB and RNG. Right now one has to have already installed the headers from the core of Numeric in order to even build these modules. The sequence is thus 1) get source 2) install the core 3) build or install the submodules As is stands, even if the Numeric core is already installed, it is not possible to make a binary distribution of the LALITE package (and maybe others). This could be fixed easily of the LALITE package, but I havn't looked to see if there are other problems with the other packages. The purpose of distutils is that the sequence for a given distribution is 1) get the source 2) build, or install, or build a binary distribution and you're done This can't be done with the way that things are organized right now. There are probably several ways to deal with this, but first a decision needs to be made as to what the goals are. As I understand it the goals are 1) keep all of the current packages in the distribution 2) the following imports will work individually or together: a) import Numeric b) import FFT c) import LinearAlgebra d) import MLab e) import Matrix f) import Precision g) import RandomArray h) import UserArray i) import ranlib j) import umath k) import RNG l) import MA 3) minimal changes in the source I just need some direction so that I can get things working. I think that the simplest thing is to merge the RANLIB and LALITE packages with the core of Numeric and make the building and installation of them an option. This fits beter with the paradigm of distutils. Tony
You wrote: ...As I understand it the goals are 1) keep all of the current packages in the distribution 2) the following imports will work individually or together: a) import Numeric b) import FFT c) import LinearAlgebra d) import MLab e) import Matrix f) import Precision g) import RandomArray h) import UserArray i) import ranlib j) import umath k) import RNG l) import MA 3) minimal changes in the source I just need some direction so that I can get things working. I think that the simplest thing is to merge the RANLIB and LALITE packages with the core of Numeric and make the building and installation of them an option. This fits beter with the paradigm of distutils. --- You are describing exactly what we used to have. We changed it. We had reasons that haven't disappeared. (1) is not necessarily a goal. We had a long argument about that, too. If anything, (1) is an anti-goal. Under no circumstances am I willing to move packages back to the core. I think it more likely that all the optional packages will go somewhere else entirely. We need a more organized structure. For historical reasons people did not want to change the way some of the above are NOT packages. (2) No, it is not possible to import those modules independently. Some depend on the others. (3) is not a goal, but it is not permissible to require changes in CLIENT code, such as changing where the include files get installed. (4) Goal: enable people to easily modify LinearAlgebra so that a user-specified BLAS and/or LAPACK library is used. (5) Goal: not make it harder to make distributions on the Mac or Windows just to make RPMs easier.
On Sun, 21 Jan 2001, Paul F. Dubois wrote:
OK, I guess I mis-rememberd the conclusion. If we have a more organized structure than I think that most of the problems would be solved. Whether RANLIB and LALITE are sub-packages of Numeric, or they are installed parallel to Numeric the setup.py scripts would be simple. If they are parallel to Numeric than they can be imported like they are now if that is a concern.
(2) No, it is not possible to import those modules independently. Some depend on the others.
All of the import lines that I gave work with the Numeric that I have installed: I left out the ones that didn't. Let me know which ones should be able to be imported and if there are any missing.
(3) is not a goal, but it is not permissible to require changes in CLIENT code, such as changing where the include files get installed.
By client code do you mean non-python code using the libraries?
(4) Goal: enable people to easily modify LinearAlgebra so that a user-specified BLAS and/or LAPACK library is used.
I've been playing with this and on *nix types systems it shouldn't be too hard to do as options to setup.py. I don't know how BLAS and LAPAK get installed on non *nix systems. My plan has been to do minimal autoconf type scanning (taking into consideration command line options) to look for existing libraries.
(5) Goal: not make it harder to make distributions on the Mac or Windows just to make RPMs easier.
I'm trying to go through distutils when the required functionality is already present so it shouldn't be mch of an issue. I do have a W2k laptop that I can test things on in extremis. The main roadblock is trying to figure out what to do with RANLIB and LALITE. Tony
On Sun, 21 Jan 2001, Tony Seward wrote:
Ah, sorry, I didn't read you post properly. I thought you were just having trouble compiling something you didn't really need, and wanted to avoid compiling it. You may already know this, but this has been discussed on the distutils-sig mailing list (and maybe this one too) just recently. I don't recall what conclusions they came to, if any - things are held up at the moment because Greg Ward just moved house and is effectively off-line. I guess when he appears again he'll be swamped, so don't hold your breath for changes in distutils itself. John
On Sun, 21 Jan 2001, John J. Lee wrote:
I'm not sure what you mean. Even './setup_all.py build' doen't work for FFT, LALITE, RANLIB and RNG. Right now one has to have already installed the headers from the core of Numeric in order to even build these modules. The sequence is thus 1) get source 2) install the core 3) build or install the submodules As is stands, even if the Numeric core is already installed, it is not possible to make a binary distribution of the LALITE package (and maybe others). This could be fixed easily of the LALITE package, but I havn't looked to see if there are other problems with the other packages. The purpose of distutils is that the sequence for a given distribution is 1) get the source 2) build, or install, or build a binary distribution and you're done This can't be done with the way that things are organized right now. There are probably several ways to deal with this, but first a decision needs to be made as to what the goals are. As I understand it the goals are 1) keep all of the current packages in the distribution 2) the following imports will work individually or together: a) import Numeric b) import FFT c) import LinearAlgebra d) import MLab e) import Matrix f) import Precision g) import RandomArray h) import UserArray i) import ranlib j) import umath k) import RNG l) import MA 3) minimal changes in the source I just need some direction so that I can get things working. I think that the simplest thing is to merge the RANLIB and LALITE packages with the core of Numeric and make the building and installation of them an option. This fits beter with the paradigm of distutils. Tony
You wrote: ...As I understand it the goals are 1) keep all of the current packages in the distribution 2) the following imports will work individually or together: a) import Numeric b) import FFT c) import LinearAlgebra d) import MLab e) import Matrix f) import Precision g) import RandomArray h) import UserArray i) import ranlib j) import umath k) import RNG l) import MA 3) minimal changes in the source I just need some direction so that I can get things working. I think that the simplest thing is to merge the RANLIB and LALITE packages with the core of Numeric and make the building and installation of them an option. This fits beter with the paradigm of distutils. --- You are describing exactly what we used to have. We changed it. We had reasons that haven't disappeared. (1) is not necessarily a goal. We had a long argument about that, too. If anything, (1) is an anti-goal. Under no circumstances am I willing to move packages back to the core. I think it more likely that all the optional packages will go somewhere else entirely. We need a more organized structure. For historical reasons people did not want to change the way some of the above are NOT packages. (2) No, it is not possible to import those modules independently. Some depend on the others. (3) is not a goal, but it is not permissible to require changes in CLIENT code, such as changing where the include files get installed. (4) Goal: enable people to easily modify LinearAlgebra so that a user-specified BLAS and/or LAPACK library is used. (5) Goal: not make it harder to make distributions on the Mac or Windows just to make RPMs easier.
On Sun, 21 Jan 2001, Paul F. Dubois wrote:
OK, I guess I mis-rememberd the conclusion. If we have a more organized structure than I think that most of the problems would be solved. Whether RANLIB and LALITE are sub-packages of Numeric, or they are installed parallel to Numeric the setup.py scripts would be simple. If they are parallel to Numeric than they can be imported like they are now if that is a concern.
(2) No, it is not possible to import those modules independently. Some depend on the others.
All of the import lines that I gave work with the Numeric that I have installed: I left out the ones that didn't. Let me know which ones should be able to be imported and if there are any missing.
(3) is not a goal, but it is not permissible to require changes in CLIENT code, such as changing where the include files get installed.
By client code do you mean non-python code using the libraries?
(4) Goal: enable people to easily modify LinearAlgebra so that a user-specified BLAS and/or LAPACK library is used.
I've been playing with this and on *nix types systems it shouldn't be too hard to do as options to setup.py. I don't know how BLAS and LAPAK get installed on non *nix systems. My plan has been to do minimal autoconf type scanning (taking into consideration command line options) to look for existing libraries.
(5) Goal: not make it harder to make distributions on the Mac or Windows just to make RPMs easier.
I'm trying to go through distutils when the required functionality is already present so it shouldn't be mch of an issue. I do have a W2k laptop that I can test things on in extremis. The main roadblock is trying to figure out what to do with RANLIB and LALITE. Tony
On Sun, 21 Jan 2001, Tony Seward wrote:
Ah, sorry, I didn't read you post properly. I thought you were just having trouble compiling something you didn't really need, and wanted to avoid compiling it. You may already know this, but this has been discussed on the distutils-sig mailing list (and maybe this one too) just recently. I don't recall what conclusions they came to, if any - things are held up at the moment because Greg Ward just moved house and is effectively off-line. I guess when he appears again he'll be swamped, so don't hold your breath for changes in distutils itself. John
participants (3)
-
John J. Lee -
Paul F. Dubois -
Tony Seward