[Distutils] Python people want CPAN and how the latter came about

[Glyph Lefkowitz]

On Dec 21, 2009, at 5:48 PM, David Cournapeau wrote:

> On Mon, Dec 21, 2009 at 7:13 PM, Lennart Regebro <regebro at gmail.com> wrote:
>> What nobody still fails to explain in this discussion is what CPAN
>> "is" and Why Python doesn't already have it.
> 
> That's not the right question to ask. The problem is not much a
> feature problem as much as a fundamental implementation and "state of
> mind". Reliable packaging requires explicit handling, where the whole
> python stack for packaging relies a lot on implicit behavior.

It is definitely the right question to ask, and it is very much a feature problem.

The missing feature is "install what I mean". easy_install is missing by default in most cases, and then broken by default when you install it.  If a fresh python install, you cannot just type "easy_install foo", or even 'cd foo; python setup.py install' and reliably get a copy of 'foo' installed for whatever user asked for it.  Instead you get piles of cryptic error messages until you learn how to use it and what command-line options to pass.

Now, CPAN is not perfect, and you can most definitely get cryptic error messages out of it.  But, *most of the time*, it just works, and *most of the time*, developers can install dependencies and users can install software without really thinking about it too hard.

Everything you're saying about mindset and standardization may be good, and in fact entirely necessary to achieving this goal.  But it is very important that, as a community, we:

  A) keep our eyes on the prize, and try to improve the default, out-of-the-box Python package installation experience wherever possible, and
  B) be clear about what the prize _is_.  It's really important to nail down what it is that we all agree needs to improve.  I say this because if someone wants to ask a question like "what is this thing that everyone seems to say we should work on", I think it's important to answer it.

In one sense of "not a feature problem", I think you're right.  The problem here is not a particular *advanced* feature, some more sophisticated option, although many features might help fix it: the problem is that the user experience of existing functionality is bad.

We're not hearing a lot of lucid articulation of what exactly the "CPAN problem" is, and I believe the reason is that when you actually look at the problems and describe them, they're easy to work around.  setup.py install doesn't work for users who aren't root?  Well, maybe that's not really a feature problem, it's a documentation problem.  For most of us it's pretty easy to set your PATH and PYTHONPATH and type --prefix and --single-version-externally-managed, and then everything works fine.  Or use something like virtualenv.  Or you can just use Python 2.6 and set only your PATH, as long as you know that Windows keeps things in one directory layout (%APPDATA%/Python) and POSIX another (~/.local/lib/site-packages).