[SciPy-dev] Technology Previews and Sphinx Docstring Annotations

[Charles R Harris]

On Thu, Nov 6, 2008 at 11:36 PM, David Cournapeau <
david at ar.media.kyoto-u.ac.jp> wrote:

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

Yes, that was my thought. Such packages shouldn't have to depend on the
release schedule of scipy proper and could almost be released by a script if
the proper machines and compilers were made available. I think this would be
a good thing for less ambitious developers who just want to contribute a
useful package and not worry about all the problems of a major scipy
release. Adding the ability to select that particular package in a bug
report would also make maintainence easier. It would be even better if the
mailer could also make the distinction so that one could subscribe to just
those reports. I don't know if that is possible, however...

Anyway, I think it would be useful to divide scipy into a core, difficult
part and an easy part. The different parts could all install into the same
folder, or be part of some super package, but the easy parts could also be
made available as separate pieces with their own version numbers. Some might
be at version 1.0 already ;)

I'm not sure how svn could be set up to support this, but Anne should be
able to check out only that part that is hers and there should be some way
of building only that part. This also implies some sort of infrastructure to
tag and release only those parts.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20081107/e42e5994/attachment.html>