[Distutils] Re: CPAN functionality for python - requirements

[Sean Reifschneider]

On Wed, Feb 28, 2001 at 09:59:38AM -0000, Moore, Paul wrote:
>MakeMaker
>---------

Handled by distutils, as you mention.

>The system of FTP sites and mirrors
>-----------------------------------

Depends on wether you want a single central location, or the ability for
packages to reside on a disperse set of machines...  My setup can handle
either.

>CPAN.pm
>-------

This is what I'm working on, though it's interface to the catalog is
fairly stand-alone instead of being dumped in a bunch of FTP directories
(as I understand being the way CPAN works).

>enough that things like FTP client support is available out of the box
>(whereas CPAN.pm won't work until you manually install libnet, and possibly

Well, yes and no...  Unfortunately, using urlretrieve on an ftp:// URL
seems to be broken at best.  In my prototyping work last night, I ended
up just calling "lftp" via os.system() -- not optimal but it was at
least working.  I need to dig into urllib some more, but at the least
it seemed to need to run in passive mode, have better handling of
malformed URLs (ftp://ftp.tummy.com//foo/bar/ was causing problems because
of the doubled "/" created by appending a base and mirror URL).  There
also seemed to be a problem with closing the session properly when
talking to an anonfile server...

>But writing a "perfect" utility for automated download-and-install, with
>dependency tracking, etc etc, is going to be VERY HARD. Don't get misled -

Can't be that hard.  I'm still working on the dependencies, but I've been
able to get the rest of it working in my copious spare time before going
to bed over the last two nights...

>The h2xs program
>----------------

That seems like a distutils tool to me.

>A social structure
>------------------

Based on my experimenting with Distutils last night, I don't know that this
will be a problem.  Distutils is totally cool -- I can't imagine going back.

>Interestingly, developers probably don't "expect" to have to include
>dependency information, and hence many don't - resulting in the problems you

I think we can deal with that in an iterative manner.  First get them to build
distutils packages, then when it fails to install on some user's machine
because they don't have foo.py we can educate them on the joys of listing
third-party module requirements.

>still (relatively) new, and so there are LOTS of packages which don't come
>with a setup.py yet. Often, adding one isn't hard, but it is still to

The biggest win of using distutils is that it makes it easier for the
developer to run their software on multiple machines.  That selfish
reason is enough for me.

>Things are looking better with Python 2.1, though. Included with 2.1, it
>looks like there will be a standard unit testing module, and a new "pydoc"
>package, which will extract documentation from module docstrings. So the

Should be sweet...

Sean
-- 
 That weapon will replace your tongue. You will learn to speak through
 it.  And your poetry will now be written with blood. -- _Dead_Man_
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python