[SciPy-dev] PRIMME: PReconditioned Iterative MultiMethod Eigensolver

Brian Granger ellisonbg.net at gmail.com
Sat Oct 28 00:26:19 CDT 2006


My few cents...

While the license issues are important, I don't think they should be
the only thing that is considered when deciding about what gets
included into scipy.  A few things that I think /should/ be strongly
considered:

 * Is the code strongly coupled to scipy already?  Does it have scipy
as a requirement?  Does it only require NumPy?

 * Does the code provide capabilities that *many* users of scipy would want?

 * Would people ever want to use the code without the rest of scipy?
If the answer is yes then I think the code should probably NOT be
included in SciPy.  Two example of projects that fit into this
category (license issues aside): pytables and mpi4py.  While one could
make an argument that scipy should include tools like these, many
people need to use these things who don't need scipy  at all.  I work
with many people who use pytables/mpi4py on supercomputers regularly -
and installing things on these systems can be a huge pain.  If these
packages were included with scipy, scpy would become a hinderance and
burden at that point.

 * NumPy goes a long way in encouranging interoperability amongst
numerical codes written in Python.  If a code already interoperates
with NumPy and SciPy is there any additional benefit to actually
including it with with SciPy?

I do think it is a good idea to keep the non BSD code in a separate
namespace (as Fernando has suggested).  Either that or they can be
hosted as separate foo.scipy.org projects like ipython.scipy.org,
pyxg.scipy.org, wavelets.scipy.org, etc.  Why not have
PyPRIMME.scipy.org?

Brian



On 10/27/06, Robert Kern <robert.kern at gmail.com> wrote:
> David Cournapeau wrote:
> > David Cournapeau wrote:
> >> I have seen scikits mentioned before already, but I didn't find an
> >> explanation on what it is (supposed to be ?) in the archive. Is it just
> >> a separate svn branch to have clean separation between code which
> >> depends on different bindings ? I am not sure to understand the link
> >> between scikits and the problem of depending on optional codes ?
> >>
> > I am sorry, I meant is scikits a separate svn branch for code which
> > depends on libraries with different *licenses* than scipy,
>
> Fernando Perez brought up the idea some time ago to establish a namespace
> package (with projects.scipy.org hosting) for valuable scipy-related projects
> that {c,w,sh}ould not actually go into scipy for whatever reason. One good
> reason would be the license.
>
> Instead of making more code based on LGPL and GPL software optional to avoid
> license hassles, it's cleaner all around to simply put the problematic code into
> a separate package.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
>   that is made terrible by our own mad attempt to interpret it as though it had
>   an underlying truth."
>    -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>


More information about the Scipy-dev mailing list