[Python-Dev] "setuptools has divided the Python community"

[Nick Coghlan]

Jeff Hall wrote:
> Someone asked for the input of "ordinary users" (i.e. non developers)
> which, unfortunately, most of the people on this list don't fall in. My
> experience with setuptools is that it's poorly documented and assumes a
> level of sophistication that isn't always there. While this is fine in a
> lot of arenas, installation of things shouldn't be an area where I have
> to guess between multiple interpretations of documentation AND have a
> thorough knowledge of some of the nuts and bolts of interdependencies.
> Maybe having an "easily extensible" language is not consistent with
> having an "easy to extend" language, but the current arrangement seems
> untenable.

I'm mostly reading this thread as an interested observer, but the
impression I'm getting is that setuptools and friends are really
*packaging tools* (designed to allow developers to communicate
information to packagers and distributors) that have been pressed into
service as *distribution tools* (designed to deliver software to end users).

That is, the full workflow that should really be happening is something
like the following:

                     Developer(s)
                          |
                          V
         (distutils/setuptools/pip/zc.buildout/etc)
                          |
                          V
             <Common Python packaging spec>
                          |
                          V
              Packager(s)/Distributor(s)
                          |
                          V
  (Windows MSI/Mac OS X bundle/Linux RPM/Linux DEB/etc)
                          |
                          V
                 End User Installation

But what appears to be currently happening is that the second half of
that process is being skipped in many cases and the "<common packaging
spec>" is instead being used as a substitute for the appropriate
platform-specific installation process.

This works fine in a centrally hosted web app development world where
the "distribution to end users" step essentially amounts to "point your
web browser at <this URL>". But for other kinds of software that is
actually installed on an end user's machine it is going to provide a
lousy installation experience.

If that perception is accurate, then any changes likely need to focus on
the *opposite* end of the toolchain: the part between the "<common
packaging spec>" and the end users.

In other words: Given an egg, how easy is it for a packager/distributor
to create a platform specific package that places the files in the
correct locations for that particular platform (regardless of how
arbitrary those rules may appear to the original developers)?

Also-not-on-the-right-continent-for-PyCon'ly,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------