[Python-Dev] PEP 365 (Adding the pkg_resources module)

Paul Moore p.f.moore at gmail.com
Thu Mar 20 21:34:18 CET 2008


On 20/03/2008, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 05:55 PM 3/20/2008 +0000, Paul Moore wrote:
>  >It's not that I object to the existence of automatic dependency
>  >management, I object to being given no choice, as if my preference for
>  >handling things manually is unacceptable.
>
> Note that easy_install has a --no-deps option, and you can make it
>  the default in your distutils.cfg file.

Sorry, I wasn't clear. There's context that helps, but even with it I
wasn't clear. Tres told me how to download all the dependencies for
use offline (which I actually knew, but that's not the point here). I
clarified that I didn't want to use dependency management but
preferred to manage dependencies manually.

I then went on to say that putting dependency information in setup.exe
and expecting users to use automatic dependency resolution encourages
developers to omit dependency details from documentation (to an extent
I can't quantify, but I believe is non-zero). That lack of
documentation "forces" me to rely on the automatic process. THAT is
the thing that removes my choice, not easy_install's ability to skip
dependency checking.

I'm sorry I wasn't clearer - but in my defence, my posting was pretty
long already and I was trying to be brief...

>  Also, setuptools-based packages *can* build bdist_wininst
>  installers.  (In fact, if memory serves, I added that feature at your request.)

I know. python setup.py bdist_wininst. And thank you for adding it.
But again you miss my point. People are starting to omit distributing
bdist_wininst installers in favour of eggs only. And you cannot (to my
knowledge) convert an egg into a bdist_wininst installer, and if you
can't compile from source (a C extension with complex dependencies,
for example) you're stuck (in the sense that you're forced to use eggs
without add/remove programs support).

>  Personally, I'm not very thrilled with the number of complaints on
>  this thread that could be resolved by RTFMing.  There are extensive
>  manuals, and they do contain the information that some people are
>  saying isn't there.  In several cases that I've seen here today
>  alone, there are actually *entries in the tables of contents* that
>  name the precise thing people here are characterizing as undocumented
>  or even *impossible*, like:
>
>  * Making your package available for EasyInstall
>  * Installing on Un-networked Machines
>  * Custom Installation Locations
>  * Restricting Downloads with --allow-hosts
>
>  It's easy to get the impression that people not only didn't RTFM,
>  they didn't even Read The Friendly Table Of Contents of the said
>  M.  Nor, when, they found something in the manual that they didn't
>  understand, write to the distutils-sig to ask anybody to explain, and
>  perhaps suggest ways the FM's could be improved.

As I said, I know there is documentation, but (a) it's very long, and
(b) it's full of jargon that you need to understand before you can
follow it. Believe me, I've tried to read it.

But ultimately, all I'm trying to do is work out how to do something
that is as simple as "download exe, run it" (on a PC with browser-only
access to the internet) in the bdist_wininst world. That's all. I'm
equally not very thrilled at having to read many pages of dense
documentation to find out how to do this. Heck, I read the
documentation twice, and asked on the distutils-sig, before I worked
out how to do easy_install -zmax (and the only reason I can remember
that now without looking it up is that "zmax" is memorable - z plus
the word max - I have no idea without going back to the manual what
the individual options do). I'd say that the documentation needs to be
better. (And I said how - a tutorial-style summary. What more should I
do short of writing it myself?)

Honestly, I'm trying to help improve (by my measure of improvement,
certainly) setuptools. I've done as much (more!) homework as I feel is
appropriate (no, I haven't studied the whole manual all the way
through). Being treated as if it's my fault, and I haven't done
enough, is both discouraging and to be honest, somewhat offensive.

I'm going to quit this thread for a while now, as I don't want to turn
things into a flamewar. I believe Tres took my points on board. I hope
others have, too. I certainly don't expect everything I say to be
taken as gospel, so that's enough for now.

Paul.


More information about the Python-Dev mailing list