Damian Eads wrote:
>> However, it seems we should be a bit more circumspect including code
> in scipy proper that depend on external libraries. Code with few if
> any dependencies seem like better candidates for inclusion. Would you
> care to clarify about what you mean because it seems like you're
> arguing the opposite?
>
It is true that packages depending on external libraries mean more work
for releasing, but OTOH, it means they are the ones who would benefit
the most from being packages inside scipy, because python build tools do
not have a good support for that case ATM. IOW, they are the ones for
which there is a clear advantage to being in scipy compared to outside
scipy tree (be it scikits or somewhere else).
> For now, it seems like deciding what to include on a case by case
> basis may be the best approach. If a developer has shown a strong
> presence on the mailing lists, has made general contributions to the
> SciPy package, has developed well-written stable production code
> tested and documented to standards, is highly likely to maintain the
> package after its release, has shown that the code compiles and passes
> tests on the architectures supported by SciPy, then the package is
> more deserving of consideration for inclusion. Not saying these
> conditions are necessary nor sufficient but they are a good rough
> guidelines about what to look for in new code.
Exactly.
David