I'd give up Perl tomorrow if only...

[Chris Liechti]

Frank Tobin <ftobin at neverending.org> wrote in
news:Pine.LNX.4.44.0206301756130.22298-100000 at palanthas.neverending.org: 

> Chris Liechti, on 2002-06-30, wrote:
> 
>> well it has. the module unittest provides all thats needed. the
>> module just needs a class derrived from unittest.TestSuite and the
>> unittest module can find the tests.
> 
> No it doesn't, for two reasons.
> 
> 1) unittest is merely a testing framework, and there is no standard
> for using it from an extracted archive.
> 
> 2) unittests are only one way to test; it is generally best suited for
> small-unit testing.  I personally use it in conjunction with
> whole-program blackbox tests.
> 
> Perl also has some fairly standard testing suites, but there is a wide
> variety you can choose from.  However, the *interface* from an
> extracted Perl module is *always* "make test".

yes, so all we need is a convention (for the interface) and a small 
addition to distutils to run the tests, right?
point 2) is irrelevant when there is a standarized interface to invoke the 
tests and return the results.

>> its also a convention to have a test() function, but the former is
>> more powerful. yes, it should be used more widely.
>> 
>> > 3) a standard installation mechanism (Perl and Python do have)
>> > 4) a standard README system (Perl has, Python doesn't)
>> 
>> i don't know the perl way but with python every object has a __doc__ 
>> attribute, every module, class, function and method etc. and with
>> pydoc there is a standard extraction tool right in the standard
>> distro. ever tried it?
> 
> I'm very familiar with docstrings.  Perl also has its POD.  But each
> of these is API information.  README's are a different sort. 
> dostrings do not substitute for what a README is for:
> 
> 1) description of the module
> 2) describes dependencies
> 3) other information that is not API-oriented

absolutely nothing speaks againts a readme (altough i would call it 
README.txt, windows frendly, ya know ;-)...  you can add it to an archive 
made by distutils etc. and most people have one when they distribute a 
module.  i think the only diffrence is that you want to declare it as a 
_must_.
a description is already in the pgk-info file if you build with distutils. 
i think the dependencies belog in there too as this is a file for the 
machine and the readme should be a file for the user (freely formated, no 
need to automaticaly extract vital pakage information from there).

>> as metioned above, python has all it needs, now if you talk of an
>> organization that runs test on non-standard extension modules, no we
>> don't have that right now. the python distro has good tests for the
>> standard lib, but as there is no organization that distributes
>> extensions, everyone is responsible for testing its modules. (there
>> are collections of modules, like The Vaults of Parnassus:
>> http://www.vex.net/parnassus/ or ActiveStates Programmer's Package
>> Manager (PPM) but thats not as strong or established as CPAN)
> 
> Yes, I'm talking about non-bundled extension modules.  That's all
> we're talking about here.  The standard lib is irrevelant to the
> discussion. 
> 
> I suggest that you be a Perl programmer for a while, and see what
> having CPAN accessible and authoring for it really is like.  You
> explicitly state you aren't familiar with it.  I've been author of a
> couple CPAN modules for about 4 years now, and an extensive user for
> just as long, and have been a Python module writer for just over a
> year now.  Python is a great language, but in terms of a reusable code
> repository, *nothing* comes close to the jewel that is CPAN.  There is
> a reason you'll hear this over and over from people coming to Python
> from Perl. 

belive me, i would also like something like CPAN. i have a module out 
in the wild too. and while i understand that it is nothing for the standard 
distro i see that a couple of people use it (at least a bunch of people 
download it each day :-) and a standard way to get it would be cool.

i think that an packaging system with dependecy- and downloadmanager, 
testing and more would be of great value. there are some beginnings of such 
a system by different people, but nothing lifted off until now.
i think, if a group of programers donated enough of their spare time and 
found a machine to run it on, a prototype could be set up fairly quick (as 
python has all (99%) it needs to build such a system. i guess required are 
some conventions for packages and a bit of code). but that needs two things 
1) someone who does the work on it 2) the community must use it (test it, 
make it usable, fill it with modules).

maybe, later when we have such a system, everybody will ask how we could 
have lived without it for such a long time... ;-)

> The Vaults and PPM just don't hold a candle to CPAN.  For all
> practical purposes, they are just big FTP repositories.

yes i know and agree, i didn't wanted to express something different. my 
point was that there are organizations that build collections of modules, 
even if they don't provide testing, dependecy management etc. (not sure 
about PPM's capabilities, though). i mean that i must have mentioned them 
in the context and the way i wrote above.

chris

-- 
Chris <cliechti at gmx.net>