A little bit else I would like to discuss

David Cournapeau cournape at gmail.com
Fri Feb 13 05:15:33 CET 2009

On Fri, Feb 13, 2009 at 12:39 PM, Damon <damonwischik at 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).



More information about the Python-list mailing list