CPAN functionality for python - requirements

Doug Hellmann doughellmann at bigfoot.com
Wed Feb 28 06:53:14 EST 2001


In article <mailman.983302211.26581.python-list at python.org>, "Sean
Reifschneider" <jafo at tummy.com> wrote:

> On Tue, Feb 27, 2001 at 06:50:52AM -0500, Doug Hellmann wrote:
>>> That seems to be where we diverge...  If somone has made an RPM of it,
>>> I'd rather have that than some files winding up hanging around my
>>> file-system.
>>
>>So why did distutils make it into the Python core?
> 
> How does distutils making it into the Python distribution rule out that
> somone may want to prefer RPMs?

It doesn't, now that I realize distutils will make RPMs.

>>3. Need to support including documentation along with source for
>>packages when
>>documentation is available.
> 
> The practice in many RPMs is that the documentation is a "sub package"
> (see my Python SRPM), which can be installed on your development
> machines, but bypassed on the production machines...
> 
> Don't get me wrong, I'm all for documentation.  The lack of "javadoc"
> for Python has really hurt though...

See http://happydoc.sourceforge.net.

>>But that leaves it up to the person posting the package to make
>>distributions in formats for any platforms where folks might want to
>>install their stuff, or to have someone *else* create those packages. 
>>That may lead to a situation
> 
> What's wrong with allowing people to select different packaging formats
> if they're available?

We still have to support *some* form of installation if the package
format you want is not available.  It sounds like the best way to handle
that is to enhance distutils to have it generate more package types as
output.

>>where someone believes that they cannot install my package on MacOS
>>because I didn't make an HQX file (or whatever) when I posted HappyDoc.
> 
> Again, my tool isn't concerned with such policies except that it allows
> the user to define it.  If the user has defined a policy of "I won't
> accept any package that's not in .hqx format", then they should indeed
> not be shown HappyDoc if it doesn't have one.  However, it would also
> allow them to say
> "I prefer .hqx files, but will take a distutils package if it's my only
> choice".  That user then *WOULD* see HappyDoc if it had a distutils
> package.
> 
>>I can go with "allow" but if we do not help then the user must specify
>>in order to get useful results from the tool, and that becomes "force."
> 
> I don't follow that logic.

If the tool says, "I'm running on a Mac therefore I want HQX files." that
may result in an artificial limit to the list of packages available,
forcing the user to install HQX files.  If the tools says, "I was told to search
for HQX files." the user has made a choice and has more responsibility to
be aware that they are only going to get HQX files and that there may be
other options for them.

Doug



More information about the Python-list mailing list