>>>>> "GvR" == Guido van Rossum <guido@beopen.com> writes: >> I *don't* think we need to maintain any such thing in the CVS >> tree -- only in the .tar.gz we let the world download. GvR> Agreed. GvR> I have to add that I'm +0 on this idea -- it would seem that if GvR> we distribute a sumo RPM distribution we'd help way more GvR> people. I think it's significantly harder to create a .tar.gz file with a configure script and a makefile that builds Python and all the third-party libraries it depends on. Does the zlib source belong in the .tar.gz? How about OpenSSL? Tcl/Tk? libc? There are at least two problems with putting anything other than Python in a .tar.gz that we distribute. First, the user who grabs it may already have some of the third-party extensions installed. Second, we have a version-skew nightmare because each library is updated at its own pace. This is why Andrew is still correct! >>>>> "AMK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes: AMK> <broken-record>The correct fix is to make it easy to AMK> automatically download & install packages automatically; AMK> distributions then become simple lists. "You want to do Web AMK> development? Grab Cookie.py, wizard.py, DocumentTemplate, ..." AMK> "Numeric work? NumPy, PhysicalValue, Snow, AMK> ..."</broken-record> The distutils plus platform-specific package management like RPM and Debian packages are the right solution. We can produce a Python package that indicates its dependence on readline, Tcl/Tk, or anything else. We can also provide a collection of Python packages via distutils that addresses the needs of particular audiences -- Web slingers, numerical analysts, etc. Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4