Not enough Python library development [was PEP scepticism] (fwd)

[Bruce Sass]

On Tue, 3 Jul 2001, Grant Griffin wrote:
> Roman Suzi wrote:
> >
> ...
> > CPyAN is much more complex task, because there are:
> ...
>
> I think the problem here might be one of marketing, combined with a lack
> of corporate sponsorship.  To that end, I propose this resource be
> called "Python Program Archive Network", or PyPAN, for short. That might
> help it attract funding from Mrs. Smith's and Sara Lee.  (Heck, if
> nothing else, maybe those ladies can contribute something tasty to the
> Python Cookbook.)
>
> <sorry>
>
> Seriously, folks, I never was a big fan of CPAN: in fact, for me, it was
> just another part of my overall poor user-interface experience with Perl
> <wink>.  Although CPAN is impressive in terms of sheer girth, the CPAN
> concept seemed to encourage large interdependencies between modules.
> Although this seems like good thing in some ways (because it indicates a
> lot of software reuse), I found it nightmarish to install even fairly
> simple packages.  (I never could get the automatic CPAN installer gizmo
> to work well--at least without giving it a great deal of manual help.)

This sounds like what I've heard about the RH `contributions'
archive... I don't think it reflects on archives in general, just
those that don't bother to maintain controls or enforce standards.

If, on the other hand, you make contributors jump through some hoops,
and do not allow submissions from anonymous contributors or those that
do not meet strict standards... it might work, and be useful... even
to those of us that already have a decent archive backing up our OS.

> Having a very large standard library seems a better solution.  (Of
> course, Perl also comes with a large standard library.)  I never seem to
> have large cross-package dependency problems with Python; my experience
> has been that nearly all packages require zero or one other packages.
> Presumably, this is a fortunate aftertaste of the fact that PyPAN is
> still just a half-baked idea.

"seems" being the key word, one person's "large" is another's "huge
and filled with stuff that don't run on my box".

> But maybe an increasingly large standard library isn't totally
> practical.  An alternative that I think would be very helpful is
> "application-targeted" distributions.  For example, someone could make a
> "Numeric" bundle of Python, including NumPy and related modules;
> likewise, there could be a "webmaster" bundle.  Of course, this takes a
> lot of time and effort for somebody to create and maintain.
> (ActiveState folks, are you listening?--given that you somehow make
> money by giving away software, the more software you give away, the more
> money you'll make <wink>.)

...the above paragraph describes what Debian's task packages do.
It works because it is backed up by a well controlled archive of
packages that meet a set of minimum standards...

...ANYTHING less is just asking, no - begging, for trouble.


As much as I am in favour of turning Python into a packaged
distribution -- if it is not top notch, don't bother.


- Bruce