[SciPy-dev] requesting feedback on/editing of scikits wiki-page

[Alexander Schmolck]

David Cournapeau <david at ar.media.kyoto-u.ac.jp> writes:

> Alexander Schmolck wrote:
>> David Cournapeau <david at ar.media.kyoto-u.ac.jp> writes:
> Well, if we have one example with many options, I guess it should not be 
> too difficult to make it up-to-date. For example, for the package I 
> would like to submit to scikits, I have a makefile which builds the pdf 
> doc using some python scripts, and try to run those scripts to make sure 
> everything is updated.

Sorry, I'm not quite clear what you are getting at, so possibly this answer
doesn't address your point at all but basically what I was trying to say is
that if you use some real package, chances are that unless gets abandonned,
someone will be pretty motivated to make sure its install works properly (even
if something in setuptools changes) -- more so than if its just a toy for the
benefit of *others*.


>>> I have mostly converted one project to scikits/setuptools, and the info 
>>> I think may be useful are:
>>>     * how to use numpy.distutils (in particular, system_info classes) ?
>>
>> Why do you want to use numpy.distutils? Doesn't setuptools provide the
>> functionality you want (it might not, but I'd personally just avoid using
>> numpy.distutils for everything for which it isn't strictly required)?
> I am using the system_info scheme from distutils (to retrieve a shared 
> library and its header). I could do without, but that would basically 
> means reimplementing system_info, I guess.

That's unfortunate -- I find numpy.distutils pretty impenetrable, and I also
tend to believe that pretty much anything that's useful about it ought to
eventually end up in setuptools, unless it's really specific to numpy or
numerical python code -- IMO numpy having so much general-purpose building
(and testing) facilities in numpy is a bad thing and increases the barrier of
entry for scikits writers and other contributors of numerical python code
unnecessarily, because the learning curve gets steeper and the number of wrong
or largely equivalent choices and combinations that won't work grows.

Of course if you manage to figure out what parts of numpy.distutils might be
helpful for scikits-users, and how to use them, please do share your insights
on the wiki -- using functionality from numpy.distutils is certainly better
than roling one's own and will likely remain necessary for some time. But I do
think that the longer term goal of the scipy-community should be to rely more
on setuptools and less on numpy.distutils functionality (as far as
non-special-purpose stuff is concerned; support for fortran stuff e.g. might
well be special-purpose enough to keep it out of setuptools).

>> Hmm, why are your trying to require('scikits')? Scikits is just a namespace,
>> so it doesn't really make sense to require it, I think (it doesn't make that
>> much sense to import it *either*, but that's just how python's module system
>> works).
>>
>> As I wrote on the wiki-page, you want to do:
>>
>>     from pkg_resources import require
>>     __version__ = require('scikits.mlabwrap')[0].version 
>>
>> substituting your project name -- doesn't that work for you?
> No, it does not. 

What happens? 

If your code doesn't have any strange dependencies and you if email it to me
(or point me to an url with a tgz), I could try and have a brief look at it,
if you want.

> I assumed the problem was with scikits, because I do 
> not have a .egg file for scikits when I install my package (whereas I 
> have a pyaudiolab.egg). But I know nothing about eggs (I do not even 
> know what they are used for).

Eggs are like jar files. Essentially they are both a distribution format (like
rpm) and an archive format from which you can run code directly.

>
> The other problem I have is that python setup.py test does not work 
> either. After some random investigation, it looks like setuptools do not 
> call check_* functions, only test_*. Does that mean I have to use only 
> check_* functions in my tests ?

[test_* you mean?]

Yes, that's what I'd suggest. check_* and bench_* are numpy.testing only --
I've never understood the point of introducing them as additional aliases for
'test*' (which is what unittest uses, by default), it just seems to create
unnecessary confusion and incompatiblity without any real benfit. Having said
that something like this should also work:

    # test_pyaudialab.py
    [...]
    def test_em():
        NumpyTest().run() # or whatever

    # setup.py
    [...]
    test_suite="scikits.pyaudiolab.tests.test_pyaudialab.test_em", 
    [...]

cheers,

'as