Anne Archibald wrote:
>> A scipy submodule will be distributed to users. It has a bug tracker,
> and other people who read the bug tracker, and can possibly fix minor
> bugs. Users can find it. It gets built and tested on all relevant
> architectures. The unit tests get rerun whenever some piece of scipy
> changes.
Scikits has a bug tracker too.
> I don't have to do *any* of that. If something goes wrong,
> okay, I can go in and try to fix it, but other than that I can leave
> the working code as it is.
Well, ok, fair enough. And in all fairness, if scipy.review is about
putting the burden on regular scipy maintainers, then I am even more
strongly against scipy.preview :) It will only make scipy release
process even more cumbersome that it already is.
I understand the concern that adding packages directly to scipy is
easier for people who want their code in. But I think you don't realize
the cost of adding code to an already big project: adding code is easy,
but once it is there, it has maintenance cost, and you can't remove it.
As an example, scipy.sparse will be the huge feature for scipy 0.7. It
has taken me half a day to solve an issue on Mac OS X; I am neither a
user nor a developer of the package. I certainly don't want to say that
scipy.sparse should not have been in scipy: I certainly think it is a
great feature (and is why I spent quite some time on something which is
not even remotely fun).
The whole reason why scipy has not seen a release if because it lacks
resources to work on it. Adding new tasks does not help, obviously.
scipy.preview makes it easier to add new code for new contributors, at
the expense of scipy developers. I am much more willing to make is
easier to add new code without adding work to scipy
>> If it were a scikit I would have to scrounge build machines,
No, you don't have to if you don't care.
> I would
> have to rerun the unit tests every time some part of scipy I depend on
> changes, I would have to set up a bug tracker
There is a scikit bug tracker:
http://projects.scipy.org/scipy/scikits
> , and I would have to
> publicize it. More, it makes it difficult for other packages: how are
> dependencies between scikits handled? Is there a way to automatically
> download and install all scikits a package depends on?
Yes, with eggs. This discussion motivated me to start something which
should have done from the beginning, an example scikits.example. Nothing
fancy, but it took me ten minutes to do it, 5 minutes to register it (it
can be done in 10 seconds, but I have a peculiar network at my lab which
makes the process cumbersome).
You can now install it with easy_install
easy_install scikits.example
You can get the sources with easy_install, too:
easy_install -eNb example scikits.example
You can also put - if you want - , a windows or a mac os X binary.
>> And: how many scikits have ever been incorporated in scipy?
None, but not any has asked. Most of them depend on non BSD code, BTW. I
personally started one scikit which I hope to see included in scipy at
some point (talkbox).
>> I can't build binary distributions at all; I don't have access to (for
> example) Windows machines. And scipy.preview is intended for code
> stable enough that breaking scipy is not a concern (i.e., not more of
> a problem than for the rest of scipy).
But you can't know it does not break if you have not used it on
supported platforms. Scipy maintainers will have to deal with this instead.
>> If scipy.preview had existed, I would have put my code there. In fact,
> if someone creates it, my code will probably be the first to be moved
> there.
My remark was not to meant to say that your code should have been done
in a scikits first. It was meant: since your code was discussed, and
since you are already a known contributor to numpy/scipy, we included
your code directly in scipy. I personally have no problem with how
things happened in that exact case. But again, this cannot scale.
cheers,
David