On Fri, Feb 13, 2009 at 12:39 PM, Damon <damonwisc...@gmail.com> wrote: > The original poster complained about needing to go off to third-party > sites to hunt for software. I wonder if the Python team has ever > considered following the lead of miktex or R, and setting up a > centralized (mirrored) repository of packages? Let anyone who wants, > submit packages.
Of course they have, that's what pypi is for. Pypi does not solve all the problems, though. > > * Like R, every time there is a new version of Python, the repository > should rebuild the packages, for all supported platforms, and make > available all those that compile cleanly. R also forces you to write > properly structured documentation for every exposed function, before > the repository will accept it. > > * Like miktex, when the user does "import foo", the Python interpreter > should (optionally) look for foo in its cached list of packages, and > download the latest version if necessary. > > This works fine for R and miktex, and it has made my life very easy. Yes, R in particular is very nice for this. But it is a complex problem - and it is even more complex for python compared to R and miktex, because python is more general. In particular, in R (and miktex I guess ?), you rarely care about having several versions installed at the same time (interpreter and/or packages), but in python, this is often useful. This complicates matter quite a bit. Having automatic download at import who annoy many users, me included. For the time being, my opinion is that the only solution for deployment on desktop apps on windows/mac os X is something like Enthought distribution, which is self contained. But when you start installing something outside Enthought, it can become tricky for "average users" (the one who don't care about the technicalities). cheers, David -- http://mail.python.org/mailman/listinfo/python-list
