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 | ncogh...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
