[Distutils] People want CPAN :-)
Glyph Lefkowitz
glyph at twistedmatrix.com
Sat Nov 7 10:11:57 CET 2009
On Nov 6, 2009, at 12:53 PM, Guido van Rossum wrote:
> I just found this comment on my blog. People have told me this in
> person too, so I believe it is real pain (even if the solution may be
> elusive and the suggested solutions may not work). But I don't know
> how to improve the world. Is the work on distutils-sig going to be
> enough? Or do we need some other kind of work in addition? Do we need
> more than PyPI?
In my experience, when users say this, they just mean "I tried
easy_install and it broke".
PyPI doesn't have some deep, fundamental, architectural issue that
prevents it from working. The user experience of it is just buggy.
Consider the difference between these two pages:
http://docs.webfaction.com/software/perl.html
http://docs.webfaction.com/software/python.html
Note that the 'python' page is more than twice as long, lists a ton of
different installation options, and includes a gigantic
"troubleshooting" section that apparently isn't necessary for perl.
Note also that the Perl page is just a series of steps describing how
to invoke the one installation mechanism, but the Python page is a
hodgepodge of qualified instructions describing different possible
mechanisms you can try. It also appears that webfaction has modified
the default environment's configuration to make their
"troubleshooting" section *shorter* than it would have to be for more
general Python software installation instructions.
The default behavior of most Python installation mechanisms - to my
knowledge, 'python setup.py install', 'easy_install', and 'pip', will
all raise exceptions by default on UNIX-y platforms, unless you're
root. On Windows (since a higher percentage of the user population
walks around with admin rights all the time), the default invocations
described by many project web pages will work if the installation is
pure-python or if the author remembered to provide a Windows binary
egg, but a common failure mode is "you don't have a compiler".
Similarly, on a Mac, you have to have Xcode installed, although Python
itself works fine if you don't, so it seems like you don't.
Many of these tools *would* work by default with a small amount of
configuration, a couple of environment variables, and clearer error
messages that indicate (A) *that* you need to install a C compiler and
(B) *where* you need to go to get a C compiler.
One project that would help a lot is just a "easy python setup"
documentation project that describes, as simply as possible, in large
fonts, how to get a working Python setup that adheres to a few
conventions. Just include the 2 lines of .bashrc and explain how to
add them; don't debate the merits of ~/bin vs. ~/.local/bin vs. ~/opt/
bin (although come on, ~/.local/bin/ is _clearly_ the right name for
it), just pick one for each platform and provide clear step-by-step
instructions for getting it to work. "put this in your ~/.bashrc:
<really big PRE tag with shell setup in it>. restart your shell."
Anybody who has selected an alternate shell or done some other prior
configuration will need to adjust their expectations, but we can worry
about supporting unusual configurations when the community has a good
answer for the default configuration. (Although this is a good reason
to do this as documentation and not attempt to write an
autoconfigurating tool: an autoconfigurating tool needs to understand
every possible nuance of the environment, but advanced users can
notice which parts of the short document might not apply to them.)
I feel like I might be repeating this a bit much, but it's a really
important point: many of the things I'm talking here are *not* about
getting the code right as part of a Python tool, but in providing an
easy, manageable way to integrate with _other_ tools that are outside
of our collective control as Python package authors: the dynamic
linker, the shell, the file manager and the C compiler (or lack
thereof). By providing a default user-home-directory installation
location, Python itself is already doing almost as much as it can; if
easy_install started installing things into that location by default
*without* any of this bootstrapping documentation (or a very, very
carefully written tool to do the bootstrapping for you) then importing
pure Python packages might work great but scripts would be broken and
any external shared libraries required by Python modules (even if they
built correctly) would just give you an ImportError.
Once we have some kind of working consensus on this setup, the tools
can change to support it: easy_install can default to installing
things in the user's home directory in the case that (A) the
environment is set up for it and (B) the user isn't an administrator.
If the environment *isn't* set up, instead of spitting out twelve
paragraphs explaining how really you should have read-write access to
the location where your pth files are stored and a link into the
middle of some dense technical reference documentation, it can just
say "read this page" and link to something that says "HERE IS A .REG
FILE THAT WILL FIX YOUR PYTHON. CLICK ON IT AND DO NOT ASK QUESTIONS."
If such a document existed, it would also be good for PyPI to link to
it prominently so that if a user comes across a package by way of a
Google search that ends at PyPI, there is a clear set of instructions
as to how to get it on their computer.
There's also something that everyone on this list can do today: every
python package author should have a clean user account, OS install,
virtual machine, or whatever; some otherwise pristine environment
where they try to follow their own installation instructions *without*
any of their usually available tools or tricks for setting up a python
development environment, and without administrator access. One thing
that always strikes me about Python hackers is that we all have
existing setups to support our own personal style of development, and
so we are somewhat insulated from the new-user-experience pain. I
think if everyone on this list did this regularly on a package with a
dozen or so dependencies, the situation would rapidly improve
regardless of my other recommendations :).
More information about the Distutils-SIG
mailing list