Python needs a CPyAN

[Stephen Ferg]

I am a very satisfied user of Python and have been for number of
years. I would never willing use another language. I wish all good
things for Python, and that moves me to express some thoughts about
Python's future prospects.

I submit that the future expansion of Python usage is constrained by
Python's lack of a CPAN-like facility, and I submit that without a
CPyAN Python will never even get close to achieving the degree of
widespread usage that Perl currently enjoys.

In saying this, I am not faulting Python's "batteries included"
philosophy or the standard library. The standard library is one of
Python's greatest strengths. The standard library is Python's "jewel
in the crown" and I whole-heartedly endorse Andrew Kuchling's recent
proposal that we focus our energies on improving it.

But there are limits to a standard library. You can't put
_everything_ into a standard library, nor would you want to. There
will always be many specialized modules that shouldn't be put into a
standard library, with new modules being developed all the time.

These not-in-the-standard-library modules -- let's call them external
modules -- are the keys to a language's growth, its popularity, and
ultimately its long-term survival. The better the support for
external modules is, the more actively that they will be used and
(more importantly) re-used. If external module support is good, that
makes it easy for developers to create external modules built on top
of existing external modules, and then to create even higher-level
external modules built on those, until a very large archive of very
powerful external modules is created. With such an archive of
external modules, it is possible to do very complex, very specialized
tasks with only a few lines of code.

Note that the key to success is not the size of the archive. CPAN is
not a success because it is large. Rather, it is large because it is
a success. CPAN is only secondarily a collection of modules.
Primarily, CPAN is a set of *capabilities*: capabilities for storing,
documenting, checking for updates, searching, downloading, testing,
and installing external modules. It includes support for creating
module tests and documentation. And it is a social organization --
the CPAN testers group -- that guarantees at least a minimal level of
quality assurance for (and therefore trust in) modules in CPAN. CPAN
(the library) is large because CPAN (the external module support
mechanism) is powerful and easy to use.

It is no good saying that Python doesn't need a CPyAN because we've
got Google, or we've got SourceForge, or we've got PyPI or distutils
or the Vaults of Parnassus. Even used together, all of these tools
still fall short of the capabilities of CPAN. Only a full CPyAN will
provide the quality and ease-of-use of external modules that will
enable Python to flourish in the coming decade.

This is _not_ to say that Python will die without a CPyAN. It will
certainly survive and thrive. But it will remain a niche language.
Without a CPyAN, Python usage and the Python community can never and
will never grow to a size that even comes close to rivalling the size
of Perl.

Some might object that Python is not in a race with Perl, or that
popularity and size shouldn't be goals: that smaller and better should
be our goal. But I submit that popularity _is_ a goal. Ask any
Python programmer what his (or her) first wish is, and you will get
the reply: "I wish I could have a job in which I could spend all of my
time (or even, _some_ of my time) programming in Python." The only
answer to that wish is popularity; such jobs won't exist until Python
becomes more popular. (The second wish is an altruistic, professional
one: "I wish I could convince my organization to use Python, because
Python really is a better technology, and my organization really does
need it." And the answer to that wish, too, lies in making Python
more popular.)

To those who treasure the standard library, and who switched to Python
to escape the need to visit CPAN for even trivial things, we can say:
that won't change. The standard library will remain as strong as
ever; CPyAN will supplement but not replace it.

To those who shrink in revulsion from everything Perlish, I say: CPAN
is a great system, regardless of who invented it. It is the best
thing about Perl. In the great tradition of Python eclecticism, let's
steal it!

Because a CPyAN is key to the long-term growth of Python, creating a
CPyAN should be one of the highest -- perhaps THE highest -- of the
Python Software Foundation's priorities. Therefore, I would like to
suggest that the Python Software Foundation issue an RFP (request for
proposal) specifically for proposals to start building a CPyAN.

Building a CPyAN will be a big job, no question. But I think that for
the Python community and for the Python Software Foundation, it should
be job number one.

-- Stephen Ferg (st***@ferg.org)

REFERENCES:

a very informative post on CPAN by Sean Reifschneider
http://groups.google.com/groups?hl=e...hon.org&rnum=6

a post by Hans Nowak
http://groups.google.com/groups?hl=e....nl%26rnum%3D8

google c.l.p for "something like CPAN"
http://groups.google.com/groups?q=%2...ff=1&scoring=d

requirements for the catalog SIG
http://www.python.org/sigs/catalog-s...uirements.html

[Mike Meyer]

Peter Hickman <pe***@semantico.com> writes:

Ville Vainio wrote:

I think you are overselling CPAN a little bit here. It is not an
absolute requirement, and I think Python can easily surpass Perl in
popularity even without CPAN functionality. Perl popularity in general
seems to be going down, and I don't think Perl is something to worry
about anymore. Hell, people rarely even mention Perl these days
anyway.

Just today we required a module that was not installed on our system.

sudo perl -MCPAN -e 'install Data::Pager'

With PyPI and distutils, we've got 90% of that already. PyPI needs to
grow a link to the tarball, and a way to turn a package name into that
link. Then you need a tool bundled with Python that gets the link from
PyPI, downloads the package, and runs "python setup.py install".

If you wanted to be brave about it, you could try scraping the
download link out of the PyPI page, then look for the link to the
tarball on that page.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[John Hazen]

[Stephen Ferg]
[ ... wants a CPyAN ...]

[John Roth]

How does the Python Package Index not meet this need?

I can think of one very serious difference, which has
kept me from placing a module in the PPI.

Ummm... Care to let us in on it? While your subtle hint may make sense
to those who have submitted packages for inclusion, I suspect I speak
for the many more of us who haven't. What's your objection?

-John Hazen

[Istvan Albert]

John Hazen wrote:

Ummm... Care to let us in on it?

typo, he probably meant

"I can't think of a ..."

[Istvan Albert]

Peter Hickman wrote:

The real trick is going to be getting the existing module authors to

The real trick is that the need for CPyAN is not an acute one.
A whole lot of tasks can be done just with the standard library.
This makes CPAN like functionality useful but not essential.
I can't think of a single instance where I would have had to
hunt down package dependencies whereas when I was using perl
that was a very significant problem where automated
installations really saved a lot of time.

Programming environments evolve like real biological systems.
They develop useful features in response to much needed
functionality and not vice versa.

Istvan.

[Graham Fawcett]

A.M. Kuchling wrote:

And it should be noted I can already install Python packages with
dependencies by running a command such as "apt-get install
python2.3-gnome2", for example.

Great point. Collectively, apt-get, yum et. al. and the underlying
package models will get far more development time, more polishing and
more real-world use than a PyPAN ever would.

Perhaps what Python needs is for Win32 to grow a working apt-get...;-)
-- G

[Ian Bicking]

Mike Meyer wrote:

Peter Hickman <pe***@semantico.com> writes:

Ville Vainio wrote:

I think you are overselling CPAN a little bit here. It is not an
absolute requirement, and I think Python can easily surpass Perl in
popularity even without CPAN functionality. Perl popularity in general
seems to be going down, and I don't think Perl is something to worry
about anymore. Hell, people rarely even mention Perl these days
anyway.

Just today we required a module that was not installed on our system.

sudo perl -MCPAN -e 'install Data::Pager'

With PyPI and distutils, we've got 90% of that already. PyPI needs to
grow a link to the tarball, and a way to turn a package name into that
link. Then you need a tool bundled with Python that gets the link from
PyPI, downloads the package, and runs "python setup.py install".

I might imagine:

python -m distutils pypi:apackage install

pypi has a download link, but it can be zipped or a tarball, and
sometimes neither, and it's not really required. And SourceForge has
its lame balancing system no matter what we do. But zip and tar can
both be handled, and SF just requires a custom link scraper. The rest
is a matter of getting people to use PyPI, and put in accurate download
links. And use trully unique names. And some other things I haven't
thought of.

--
Ian Bicking / ia**@colorstudy.com / http://blog.ianbicking.org

[EP]

Building a CPyAN will be a big job, no question. But I think that for
the Python community and for the Python Software Foundation, it should
be job number one.

I must admit I found CPAN quite nice when I used Perl, and it would be terrific to have an equivalent for Python modules, at least for those of us using Windows boxes.

but... sometimes it's a matter of a bridge too far.

Afterall, the Perl guys had more than one way to do it (CPAN)...


P.S. if Python reflects original thinking, why are so many Python modules named " py "?

[bruno modulix]

Michael Ströder a écrit :

Peter Hickman wrote:

Just today we required a module that was not installed on our system.

sudo perl -MCPAN -e 'install Data::Pager'

And it was installed with all it's dependencies.

I'd rather call that a security and maintenance nightmare...

<aol>
We had some program (can't remember if it was spamassassin or an
antivir, I'm not the sysadmin !-) gone mad and all our customers mails
blocked for a full day because of such a wonderfull update of a perl
module...
</aol>

[Jonathon Blake]

Stephen wrote:

Python's lack of a CPAN-like facility,

CPAN is useful, _if_ you know the name of the file you want.
When you don't know the name of the file, it isn't that useful.

I'll grant that something like CPAN would mean that Anaconda, PyAstro
and the like wouldn't disappear from the Python World.

xan

jonathon

[Gerhard Haering]

On Tue, Nov 02, 2004 at 11:41:18PM +0100, bruno modulix wrote:

Michael Ströder a écrit :

Peter Hickman wrote:

Just today we required a module that was not installed on our system.

sudo perl -MCPAN -e 'install Data::Pager'

And it was installed with all it's dependencies.

I'd rather call that a security and maintenance nightmare...

<aol>
We had some program (can't remember if it was spamassassin or an
antivir, I'm not the sysadmin !-) gone mad and all our customers mails
blocked for a full day because of such a wonderfull update of a perl
module...
</aol>

Well, could have happened with a Debian[*] or *BSD, etc. update as well,
right?

-- Gerhard
[*] -testing or -unstable
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBiBR8dIO4ozGCH14RAuVDAJ4g1pz7d5BBDS0DvA6cd7 Od3ly6AQCgsBG+
ApTriS1WdfxzQVmAM2VN28w=
=3Vz3
-----END PGP SIGNATURE-----

[Steve Holden]

Graham Fawcett wrote:

A.M. Kuchling wrote:

And it should be noted I can already install Python packages with
dependencies by running a command such as "apt-get install
python2.3-gnome2", for example.

Great point. Collectively, apt-get, yum et. al. and the underlying
package models will get far more development time, more polishing and
more real-world use than a PyPAN ever would.

Perhaps what Python needs is for Win32 to grow a working apt-get...;-)
-- G

And don't I remember that yum is written in ... Python?

regards
Steve
--
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC [phone]

[John Roth]

"John Hazen" <py*********@hazen.net> wrote in message
news:ma**************************************@pyth on.org...

[Stephen Ferg]
[ ... wants a CPyAN ...]

[John Roth]

How does the Python Package Index not meet this need?

I can think of one very serious difference, which has
kept me from placing a module in the PPI.
Ummm... Care to let us in on it? While your subtle hint may make sense
to those who have submitted packages for inclusion, I suspect I speak
for the many more of us who haven't. What's your objection?

1. Where do I store the module? I don't have a web site, and
it isn't on sourceforge.

2. For what I've done, the standard installer script required
for PPI is stoopid. All that's really needed to install is unpack
to the right directory. That's it. However, to use distutils I
had to write a packager program to create all the entries
I needed. This took me quite a few hours and left a very
sour taste since a lot of things that I thought should have
been automatic weren't.

That's why the Python port of FIT isn't on PPI. And
it won't be on PPI until I get around to moving it to
Sourceforge, which will happen sometime in the very
misty future.


-John Hazen

[John Roth]

"Istvan Albert" <ia*****@mailblocks.com> wrote in message
news:g8********************@giganews.com...

John Hazen wrote:

Ummm... Care to let us in on it?

typo, he probably meant

"I can't think of a ..."

You may think you're funny.
You're not.

John Roth

[Isaac To]

>>>>> "Gerhard" == Gerhard Haering <[e-mail]> writes:

Gerhard> Well, could have happened with a Debian[*] or *BSD,
Gerhard> etc. update as well, right?

Yes, userss of systems with proper package management shouldn't want
to install anything from CPAN. On the other hand, there are many
people who are stuck with a braindead distribution or even OS that
doesn't have proper package management, or whose packages are severely
limited.

Regards,
Isaac.

[Michael Ströder]

Gerhard Haering wrote:

On Tue, Nov 02, 2004 at 11:41:18PM +0100, bruno modulix wrote:

<aol>
We had some program (can't remember if it was spamassassin or an
antivir, I'm not the sysadmin !-) gone mad and all our customers mails
blocked for a full day because of such a wonderfull update of a perl
module...
</aol>

Well, could have happened with a Debian[*] or *BSD, etc. update as well,
right?

Yes.

Ciao, Michael.

[Mike Meyer]

Isaac To <ik****@netscape.net> writes:

>> "Gerhard" == Gerhard Haering <[e-mail]> writes:

Gerhard> Well, could have happened with a Debian[*] or *BSD,
Gerhard> etc. update as well, right?

Yes, userss of systems with proper package management shouldn't want
to install anything from CPAN. On the other hand, there are many
people who are stuck with a braindead distribution or even OS that
doesn't have proper package management, or whose packages are severely
limited.

Actually, what people on systems with proper package management want
is packages that pull stuff from CPAN and install them as
packages. Doing this right is hard, because CPAN makes assumptions
about where things are liable to be installed. For Python, what we
want are packages that use distutils to install them as
packages. Doing this right is trivial, because distutils gets all the
relevant information from the environment.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

"John Roth" <ne********@jhrothjr.com> writes:

"John Hazen" <py*********@hazen.net> wrote in message
news:ma**************************************@pyth on.org...
1. Where do I store the module? I don't have a web site, and
it isn't on sourceforge.
Ok, that's a definite need. Possibly python.org could host a mechanism
to allow people to post modules. I'd do it myself, but I'm not sure
how long I'm going to have my current net connection for.
2. For what I've done, the standard installer script required
for PPI is stoopid. All that's really needed to install is unpack
to the right directory. That's it. However, to use distutils I
had to write a packager program to create all the entries
I needed. This took me quite a few hours and left a very
sour taste since a lot of things that I thought should have
been automatic weren't.

I found the standard installer script trivial to set up. If it took
hours, then you're doing something wrong. It even made it possible for
me to distribute C modules to Windows, whereas those trying to build
the module on Windows prior to me putting it into distutils never
succeeded.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Nick Craig-Wood]

Mike Meyer <mw*@mired.org> wrote:

Actually, what people on systems with proper package management want
is packages that pull stuff from CPAN and install them as
packages.
Absolutely!

For instance with Debian and Perl, dh-make-perl will turn a perl
module (tar.gz or straight from CPAN) into a .deb which you then
managage as normal. When using Debian I never use CPAN and always
dh-make-perl because I'd much rather have the package managed via
dpkg/apt-get.

That said I haven't found many perl modules that I wanted that weren't
already packaged for Debian. The same with python modules too.
Doing this right is hard, because CPAN makes assumptions
about where things are liable to be installed.
No idea how dh-make-perl works. It does though!
For Python, what we want are packages that use distutils to install
them as packages. Doing this right is trivial, because distutils
gets all the relevant information from the environment.

distutils already knows how to make .rpm files.

Eg choosing a package at the top of PyPI :-

# Download
wget 'http://ftp.livinglogic.de/xist/ll-xist-2.6.1.tar.gz'
# Unpack
tar zxvf ll-xist-2.6.1.tar.gz
cd ll-xist-2.6.1
# Make rpm
python setup.py bdist_rpm
# Make deb
cd dist/
fakeroot alien ll-xist-2.6.1-1.i386.rpm ll-xist-2.6.1-1.i386.deb
# Install with package manager
sudo dpkg -i ll-xist_2.6.1-2_i386.deb

This hasn't worked with every package I've tried it with though!

....

To make PyPI into a CPAN replacement it needs to
1) make all the submitters use distutils, and automatically test the packaging
2) host the source tar balls
3) have a system of mirrors and provide this list for download
4) provide dependency information (maybe this should be in the distutils
information in the package)
5) Provide the list of packages, descriptions, and dependencies for
download
6) Some sort of review system (maintainers, peer review, rating etc)
for each package for quality assurance

Given all that the an automatically download package x + dependencies
program would be easy.

A cross platform software repository like this would be a goal well
worth aiming for IMHO! PyPI is an excellent start though.

--
Nick Craig-Wood <ni**@craig-wood.com> -- http://www.craig-wood.com/nick

[Eric S. Johansson]

Nick Craig-Wood wrote:

Mike Meyer <mw*@mired.org> wrote:

Actually, what people on systems with proper package management want
is packages that pull stuff from CPAN and install them as
packages.

Absolutely!

For instance with Debian and Perl, dh-make-perl will turn a perl
module (tar.gz or straight from CPAN) into a .deb which you then
managage as normal. When using Debian I never use CPAN and always
dh-make-perl because I'd much rather have the package managed via
dpkg/apt-get.

That said I haven't found many perl modules that I wanted that weren't
already packaged for Debian. The same with python modules too.

Doing this right is hard, because CPAN makes assumptions
about where things are liable to be installed.

No idea how dh-make-perl works. It does though!

For Python, what we want are packages that use distutils to install
them as packages. Doing this right is trivial, because distutils
gets all the relevant information from the environment.

distutils already knows how to make .rpm files.

Eg choosing a package at the top of PyPI :-

# Download
wget 'http://ftp.livinglogic.de/xist/ll-xist-2.6.1.tar.gz'
# Unpack
tar zxvf ll-xist-2.6.1.tar.gz
cd ll-xist-2.6.1
# Make rpm
python setup.py bdist_rpm
# Make deb
cd dist/
fakeroot alien ll-xist-2.6.1-1.i386.rpm ll-xist-2.6.1-1.i386.deb
# Install with package manager
sudo dpkg -i ll-xist_2.6.1-2_i386.deb

This hasn't worked with every package I've tried it with though!

...

To make PyPI into a CPAN replacement it needs to
1) make all the submitters use distutils, and automatically test the packaging
2) host the source tar balls
3) have a system of mirrors and provide this list for download
4) provide dependency information (maybe this should be in the distutils
information in the package)
5) Provide the list of packages, descriptions, and dependencies for
download
6) Some sort of review system (maintainers, peer review, rating etc)
for each package for quality assurance

Given all that the an automatically download package x + dependencies
program would be easy.

I have provided a some of this functionality in raging dormouse.
http://harvee.org/stamper/raging_dormouse/

can download from the sourceforge "click a link" maze or a regular web
site.
Verifies checksum of package.
Can handle list of download sites to try (could be expanded to mirror
list)

the build script in raging_dormouse is fairly application-specific. It
wouldn't be hard to redraft it as a configuration file driven process
while rewriting it in Python vs. its current Bash incarnation.

you're welcome to it if you find useful.

---eric

[John Roth]

"Mike Meyer" <mw*@mired.org> wrote in message
news:x7************@guru.mired.org...

"John Roth" <ne********@jhrothjr.com> writes:

"John Hazen" <py*********@hazen.net> wrote in message
news:ma**************************************@pyth on.org...
1. Where do I store the module? I don't have a web site, and
it isn't on sourceforge.
Ok, that's a definite need. Possibly python.org could host a mechanism
to allow people to post modules. I'd do it myself, but I'm not sure
how long I'm going to have my current net connection for.

2. For what I've done, the standard installer script required
for PPI is stoopid. All that's really needed to install is unpack
to the right directory. That's it. However, to use distutils I
had to write a packager program to create all the entries
I needed. This took me quite a few hours and left a very
sour taste since a lot of things that I thought should have
been automatic weren't.

I found the standard installer script trivial to set up. If it took
hours, then you're doing something wrong. It even made it possible for
me to distribute C modules to Windows, whereas those trying to build
the module on Windows prior to me putting it into distutils never
succeeded.

Oh, the standard installer would have been fine - if all I
was distributing was Python modules. However, I have
a fairly large number of examples and quite a large amount
of HTML documentation. For some reason, the standard
installer decided that it would copy them to the install file
just fine, and then not install them. Nothing I could do would
make them install other than listing each and every file in
the install script, individually and by hand.

That's absolutely stoopid when they go into the exact
same directory they came out of. The time was spent

1) asking for help on the newsgroup. Nobody had any
helpful suggestions.

2) Hammering on the thing trying to make it work.
No joy.

3) Writing a small script to build the distutils script.
That worked, although there still seems to be an
intermittant problem on the install.

John Roth
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more
information.

[Stephen Ferg]

> Lots of people *want* a PyPAN; the number of people willing to work on it is about zero.

Admitted. Or perhaps those with the skills needed for the work aren't
able to undertake such a big job without financial support. That's why
I proposed that PSF put out a special RFP for grant money to seed the
work. My whole post was an argument for that proposal. Here's the
argument in a nutshell.

**********************************************

PSF's mission is (among other things) to support Python's long-term
sucess.

Popularity is part of what it means to be successful. Popularity is
important to the Python community because it means jobs for Python
developers, and usage of Python by organizations that need it.

Python will never catch up to Perl in popularity without CPAN-like
support.

Therefore, Support for CPAN-like capabilities for Python is critical
to Python's long-term success.

Therefore, in keeping with its mission, PSF should offer grants
specifically targeted at producing a CPyAN.

***********************************************

This issue should be of critical interest to all Python developers,
because it means the difference between the existence and the
non-existence of opportunities for developers to use Python on the
job.

[Ville Vainio]

>>>>> "Steve" == Stephen Ferg <st***@ferg.org> writes:

Steve> This issue should be of critical interest to all Python
Steve> developers, because it means the difference between the
Steve> existence and the non-existence of opportunities for
Steve> developers to use Python on the job.

If it was that important, I suppose the catalog-sig would have, say,
one non-spam message in the recent months. Perhaps people have assumed
that PyPI and distros' own package systems have solved the problem
already.

It should be noted that many significant Python packages have
non-python dependencies (wxPython <- wxWidgets). That kind of
dependency needs to be handled too, and it's the kind that is most
problematic. So in the end it basically boils down to not having
apt/yum for Windows.

--
Ville Vainio http://tinyurl.com/2prnb

[Stephen Ferg]

> Hell, people rarely even mention Perl these days

-----------------------------------------
location number of hits for
Python Perl
-----------------------------------------

Monster.com 18 552

Washington Post
classifieds 25 353

InfoWorld 81 954
job openings

TotalJobs (British) 32 200

[Peter Hickman]

Ville Vainio wrote:

Hell, people rarely even mention Perl these days anyway.

People hardly speak Mandarin Chinese these days, I can go months without hearing
any being spoken. Same goes for Urdu and Spanish.

Today we learn the difference between an 'opinion' and an 'informed opinion'.

[A.M. Kuchling]

On 3 Nov 2004 06:04:44 -0800,
Stephen Ferg <st***@ferg.org> wrote:

Admitted. Or perhaps those with the skills needed for the work aren't
able to undertake such a big job without financial support. That's why

I'm doubtful that waving money in the air will magically produce volunteers,
but who knows? I suggest you present your proposal to the PSF; I suppose
the Board would be the group that would consider it.

--amk

[Ville Vainio]

>>>>> "Steve" == Stephen Ferg <st***@ferg.org> writes:

Hell, people rarely even mention Perl these days

Steve> -----------------------------------------
Steve> location number of hits for
Steve> Python Perl
Steve> -----------------------------------------

Steve> Monster.com 18 552

.... etc.

This does not take away the fact that a few years ago, it was felt
that Python is in a bloody fight over popularity with Perl. It was
felt that Perl still had this or that over Python; this doesn't seem
to be the case anymore. Python is no longer the obscure up-and-coming
scripting language. It is used in several high-profile places, while
Perl usage seems to be mostly going down in popularity. In the Open
Source world, Python aleady seems to have a higher profile than
Perl. The popularity of Python is already big enough to not be an
impediment for the company to switch over - it may be that there is
still a need to switch over in the first place, but that's just a
refreshing challenge ;-). Hence, I wouldn't be too worried about
competing with Perl.

Decision to use a library requires some thinking already, it's not a
big additional hurdle to download it from SF/whatever and add it to
the company version control system. I wouldn't mind a CPANish system,
but the lack of it isn't the bottleneck in Python adoption.

--
Ville Vainio http://tinyurl.com/2prnb

[Thomas Heller]

"Graham Fawcett" <gr************@gmail.com> writes:

A.M. Kuchling wrote:

And it should be noted I can already install Python packages with
dependencies by running a command such as "apt-get install
python2.3-gnome2", for example.

Great point. Collectively, apt-get, yum et. al. and the underlying
package models will get far more development time, more polishing and
more real-world use than a PyPAN ever would.

Perhaps what Python needs is for Win32 to grow a working apt-get...;-)

The distutils' created bdist_wininst installers in principle have all
that is needed to build something like that. Except command line flags
for silent installation, maybe. But since a silent installer has no
need to display a user interface, it would be simple to write a
bdist_wininst_silent in pure Python.

Thomas

[Alex Martelli]

Ville Vainio <vi***@spammers.com> wrote:

Python is no longer the obscure up-and-coming
scripting language.

Yep, that's what Ruby is for.
Alex

[Stephen Ferg]

> I suggest you present your proposal to the PSF; I suppose

the Board would be the group that would consider it.

I agree.

I attempted to post it to the grants-discuss list, but was turned
down.

"Interesting discussion, but I don't think the grants-discuss list is
the right place for it."