[Distutils] Re: CPAN functionality for python - requirements

[John J. Lee]

On Wed, 28 Feb 2001, Sean Reifschneider wrote:

> On Wed, Feb 28, 2001 at 09:59:38AM -0000, Moore, Paul wrote:
[...]
> >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.

I think an iterative approach is a recipe for an archive full of packages
that only very patchily take advantage of all the facilities on offer.
The perl approach of making 'stubs' generation very easy for tests, docs,
etc. is a very good idea -- it encourages you to actually put something
more useful in the stubs (if not immediately, then later on).  It's self
perpetuating: they're always generated and the standard instructions for
uploading stuff say you should include them (presumably), so it becomes
widespread in the archive; people making new packages then see that
everyone makes packages that way, so they'll do the same thing.

I'm not suggesting everyone's about to start writing huge comprehensive
manuals and test suites for everything, but a little encouragement and
standardisation can go a long way, with a relatively small effort on the
part of the developer.  Same for dependencies, even more so probably.

> >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.

And, as selfish users of other people's software, you can use that as a
hook to get people to start making documentation and tests at the same
time.  Getting started is often the 'rate limiting step'.

> >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...
[...]

Especially if this and PyUnit, and whatever else, can all be tied together
in Distutils.  But *only* if there are actually some proper docs and good
howto examples for Distutils itself!!  What happened to the effort a while
back on that?  What remains to be done -- a todo list would be useful to
spread the load, wouldn't it?


John