Multi-distribution distributions
I'm somewhat surprised by the fact that some distributions (e.g. Numpy, Zodb) have multiple setup.py programs. As far as I know, these setup.py's do not share information so there is no way to do a bdist_wininst or bdist_rpm that builds a single distribution for these multiple sub-packages. I see this as a fairly large problem! The bdist_ functions are an important part of Distutils functionality. Paul Prescod
Explanation: we made these packages optional partly because they ought to be optional but partly because one of them depends on LAPACK and many people wish to configure the packages to use a different LAPACK than the limited "lite" one supplied. It would be correct in the spirit of SourceForge and Python packages to make every single one of these optional packages a separate "project" or at least a separate download. That would raise the overhead. Technically the manual should be split up into pieces too. I don't think all that trouble is worth undergoing in order to "solve" this problem. So, you could just build separate rpms for each of the optional packages. They are NOT subpackages in the true sense of the word, except that a couple of them install into Numeric's directory for backward compatibility. Numeric is not a true package either. Again, people have argued (and I agree) that purity of thought is trumped by backward compatibility and that we should leave well enough alone. You are welcome to add a script which runs the bdist functions on all the optional packages, in much the same way setup_all.py works. You do need to face the issue if making a bdist for the public of which LAPACK you use on which platform. I believe I was one of the earliest and hardest pushers for Distutils, so I have no trouble agreeing with your goals. -----Original Message----- From: numpy-discussion-admin@lists.sourceforge.net [mailto:numpy-discussion-admin@lists.sourceforge.net]On Behalf Of Paul Prescod Sent: Thursday, January 04, 2001 5:22 PM To: distutils-sig@python.org Cc: akuchlin@mems-exchange.org; numpy-discussion@lists.sourceforge.net Subject: [Numpy-discussion] Multi-distribution distributions I'm somewhat surprised by the fact that some distributions (e.g. Numpy, Zodb) have multiple setup.py programs. As far as I know, these setup.py's do not share information so there is no way to do a bdist_wininst or bdist_rpm that builds a single distribution for these multiple sub-packages. I see this as a fairly large problem! The bdist_ functions are an important part of Distutils functionality. Paul Prescod _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
"Paul F. Dubois" wrote:
Wow, your "lite" module is half a meg. I'd hate to see the heavy version. :) I may not understand the extension so please tell me if I'm off-base: Would it be simpler to have a single setup.py and a set of flags to turn on and off each of the "secondary" extensions?
You are welcome to add a script which runs the bdist functions on all the optional packages, in much the same way setup_all.py works.
If I did this, I would consider a different strategy. I would suggest that each of the setup.py's could move their "setup" function into an if __name__=="__main__" block. Then setup_all.py could import each one (a little trickery needed there) and then combine the symbols like sourcelist, headers, ext_modules and so forth.
I would expect to use lapack_lite.pyd. It's easy enough to override it by copying a custom lapack on top. Paul Prescod
Explanation: we made these packages optional partly because they ought to be optional but partly because one of them depends on LAPACK and many people wish to configure the packages to use a different LAPACK than the limited "lite" one supplied. It would be correct in the spirit of SourceForge and Python packages to make every single one of these optional packages a separate "project" or at least a separate download. That would raise the overhead. Technically the manual should be split up into pieces too. I don't think all that trouble is worth undergoing in order to "solve" this problem. So, you could just build separate rpms for each of the optional packages. They are NOT subpackages in the true sense of the word, except that a couple of them install into Numeric's directory for backward compatibility. Numeric is not a true package either. Again, people have argued (and I agree) that purity of thought is trumped by backward compatibility and that we should leave well enough alone. You are welcome to add a script which runs the bdist functions on all the optional packages, in much the same way setup_all.py works. You do need to face the issue if making a bdist for the public of which LAPACK you use on which platform. I believe I was one of the earliest and hardest pushers for Distutils, so I have no trouble agreeing with your goals. -----Original Message----- From: numpy-discussion-admin@lists.sourceforge.net [mailto:numpy-discussion-admin@lists.sourceforge.net]On Behalf Of Paul Prescod Sent: Thursday, January 04, 2001 5:22 PM To: distutils-sig@python.org Cc: akuchlin@mems-exchange.org; numpy-discussion@lists.sourceforge.net Subject: [Numpy-discussion] Multi-distribution distributions I'm somewhat surprised by the fact that some distributions (e.g. Numpy, Zodb) have multiple setup.py programs. As far as I know, these setup.py's do not share information so there is no way to do a bdist_wininst or bdist_rpm that builds a single distribution for these multiple sub-packages. I see this as a fairly large problem! The bdist_ functions are an important part of Distutils functionality. Paul Prescod _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
"Paul F. Dubois" wrote:
Wow, your "lite" module is half a meg. I'd hate to see the heavy version. :) I may not understand the extension so please tell me if I'm off-base: Would it be simpler to have a single setup.py and a set of flags to turn on and off each of the "secondary" extensions?
You are welcome to add a script which runs the bdist functions on all the optional packages, in much the same way setup_all.py works.
If I did this, I would consider a different strategy. I would suggest that each of the setup.py's could move their "setup" function into an if __name__=="__main__" block. Then setup_all.py could import each one (a little trickery needed there) and then combine the symbols like sourcelist, headers, ext_modules and so forth.
I would expect to use lapack_lite.pyd. It's easy enough to override it by copying a custom lapack on top. Paul Prescod
participants (2)
-
Paul F. Dubois -
Paul Prescod