[SciPy-dev] the scipy mission, include finite element solver

[Ondrej Certik]

On Wed, Apr 15, 2009 at 3:20 AM, Dag Sverre Seljebotn
<dagss at student.matnat.uio.no> wrote:
> Ondrej Certik wrote:
>> On Wed, Apr 15, 2009 at 2:09 AM, Dag Sverre Seljebotn
>> <dagss at student.matnat.uio.no> wrote:
>>> Dag Sverre Seljebotn wrote:
>>>> David Cournapeau wrote:
>>>>> On Wed, Apr 15, 2009 at 8:37 AM, Andrew Straw <strawman at astraw.com> wrote:
>>>>>
>>>>>> Well, fink ports the Debian package management to Mac OS X. Does
>>>>>> something equivalent exist for Windows? The actual Debian file formats
>>>>>> are pretty simple, so it seems like it should be do-able.
>>>>> What makes debian such a well integrated system is not so much the
>>>>> scripts - after all, rpm .spec files, debian files, port (BSd system)
>>>>> files are not that different. What matters is how polish the actual
>>>>> packages are. That's already difficult to do for one platform. That
>>>> +1
>>>>
>>>> The reason Sage installs works is because Michael Abshoff works as
>>>> release manager. Making sure, e.g., that one software package isn't
>>>> upgraded until the rest of the packages can handle the upgrade.
>>>>
>>>> Ondrej, will SPD be keyed to Sage releases? Otherwise SPD will be
>>>> something that works at one point in time, but then requires fulltime
>>>> supervision to keep it working, and really not much better than
>>>> setuptools foir the reasons David mentions.
>>> The major point I'm trying to make here is that if you have Sage version
>>>  x.y.z, that autoatically implies Python version a.b, NumPy version c.d
>>> and SciPy version e.f; all tested by someone else to fit together.
>>>
>>> Unless the same will be the case for SPD, it just won't work as it must.
>>> And if it is not keyed 1:1 to Sage releases, there's going to be much
>>> work duplication.
>>>
>>> The package system is not the problem; distribution maintainance is.
>>
>> Yep, that's why I chose Sage, because in my experience Sage is by far
>> the most tested and robust opensource source distribution.
>>
>> Besides that, both William and Michael are interested in helping me
>> out, for example William and Mike Hansen just spent an evening
>> disentangling the Sage notebook, so that we can use it in SPD and they
>> can use it in the windows port:
>>
>> http://trac.sagemath.org/sage_trac/ticket/5789
>>
>> while in the scipy community, unfortunately, I can still see many
>> doubts if this effort is really needed/worthy, etc. So I first need to
>> deliver some results, then hopefully more people will join. I can't do
>> this myself alone, so I chose Sage.
>
> Well, I'm not really part of the SciPy community, but now that I
> understand the project better I'm very positive. Especially since it
> seems it will bring nice cleanups to the Sage codebase. Good luck with it!
>
> (Myself I will probably just continue to use the gigabyte of disk space
> for a full Sage (what is 1 gig anyway in this day and age?), but I
> understand that others have other needs -- especially Windows support).

It's not only about 1 gig --- first it takes long time to download for
me, it takes about 30 min to unpack on my slow laptop, but that could
be overcome -- a big problem is that Sage doesn't build on our cluster
(some problems in some math packages, that I don't need), that's a
showstopper. SPD does build there.

Plus I want to create custom all in one solutions for our code, e.g.
for PDE, so the result will be much more than 1 gig after including
all the custom code (e.g. all solvers, etc.).

Ondrej