[SciPy-dev] mlabwrap 2.0 vs. mlabwrap 1.1/1.5

[Alexander Schmolck]

Hi Matthew,

I'm sorry answering this took so long.

"Matthew Brett" <matthew.brett at gmail.com> writes:

> Hi,
>
>> What are your reasons for wanting to get out a scikits release first and
>> foremost? I ask because I'm a bit reluctant to release a repackaged mlabwrap
>> 1.0 as scikits.mlabwrap 1.1, unless it solves some concrete problem.
>
> I would have thought this would be a useful step.  

Maybe it is. I suggest the following:

    1. We make a list of things, dates and responsibities for a 1.1 milestone
       (getting svn on scipy.org and figuring out how do use trac for scikits,
       etc. see my other email would be my first priorities)
    2. We do them
    3. We make either an official or a dev egg release 

I'm willing to make an official release if everyone else still thinks this is
the best at that point; but I'll try to explain again below why I think doing
a dev scikit.mlabwrap release and instead releasing mlabwrap1.0.1 now might be
better.

> It will get people used to the scikits location,

Yes.

> provide a scikits example for other projects,

I agree it's nicer if there's an offical relase, but isn't it enough if there
is a dev version and something in svn together with some reasonable
documentation for mlabwrap to serve as an example for other projects? I've put
some effort into writing the scikitis wiki page,
<http://projects.scipy.org/scipy/scikits>, because I think that's most
important, but it clearly needs some more work (and by someone better
qualified).

> remove numarray numeric compatibility issues, thus simplifying the install.

(only Numeric actually, numarray was never supported); I might be wrong but I
don't think that the ability to use Numeric will lead to many installation
complications. IIRC all complications that people have reported fall into 2
categories

1. building *any* type of python extension on windows
2. matlab's very peculiar ideas under what compiler-version/shell etc. it
   deigns to allow you to build something uses its engine interface and
   proudces more than the single informative error message "can't open
   engine".

It's possible that setuptools will make marginally alleviate 1. OTOH I have
eventually managed to get user contributed binaries, which IMO present a
superior solution for most windows users who are not used to building stuff
themselves.

<http://projects.scipy.org/scipy/scikits>

> Also the rpath stuff will help the install,

Yes, I think your rpath tip is very helpful which is why I intend to do a
mlabwrap.1.0.1 maintance release that contains it, unless we do the
scikitis.mlabwrap release now.

> and those of us using mlabwrap in larger projects should have fewer
> places to point at for installation instructions as sckits gets going.

Well, currently mlabwrap is still the only scikit so I hope by the time that
becomes an issue, 2.0 is pretty far ahead. 

Currently there is a single webpage; we 

> I doubt the differences in the import statement will bother many of
> us.

No, but it might bother some people if a few weeks later they easy_install a
new version of scikits.mlabwrap (say 1.5) and all their code suddently breaks.
It causes even more bother if you discover that you've accumulated several
files that ``import scikits.mlabwrap`` but suddenly behave subtly different
(not an unrealistic scenario, given that the default proxying and conversion
behavior is under scrutinity).

It's certainly something I often found annoying with scipy years ago and
rarely still with matplotlib, e.g. I want to do some plots again but they no
longer work or look different and I have to figure out what version that might
have been and what changed. I'm not advocating backwards-compatibility at all
costs, and these projects still have 0.x version numbers and therefore every
right to adjust their interfaces but it seems to me that

1. There is already a viable, stable and well-documented version of mlabwrap
   that seems to fit most peoples' needs.

   IMO with 1.0final there is a stable, documented and fairly easy to install
   version of mlabwrap currently available. Since various people have helped
   out by making the install easier (by providing binaries and patches and
   info for windows and OS X) and all the questions and requests I've been
   getting deal with install related issues (no bug reports or feature
   requests) I am tempted to conclude that, regardless of all the things that
   mlabwrap undoubtedly could do better or doesn't support at the momen, as
   far as most current users are concerned, there aren't any glaring problems
   or omissions in functionality in mlabwrap that prevent them from using it
   productively (the other interpretation is of course that once they managed
   to install they immediately ran away in disgust ;).

2. We can more easily minimize user headache resulting from incompatible
   changes if they coincide with the first release of matlab as a scikit; at
   the same time it's easy to relase dev builds for people who do want
   someting more bleeding edge.
   
3. The stuff we're contemplating on doing for mlabwrap 2.0 isn't all that hard
   and shouldn't take that long. I think we've got a pretty good idea of what
   we want and I don't think that it should take me more than a week of
   full-time work to implement the required functionality, unless the design
   turns out to be flawed; I think it should be rather less effort than what
   I've spent so far in the scikikit conversion process (exchanging emails,
   getting to grips with setuptools and other infrastructure and documenting
   it on the wiki for other prospective authors etc.).

   I think the tricky bit is more likely to be choosing the right results and
   fine tuning other interface matters, for which qutie a bit of user-feedback
   will be needed -- but just getting a 2.0 alpha ready shouldn't take that
   much more time than doing 1.1.

4. I'm really spending more time on mlabwrap than I can afford right now, so
   work load is also a real issue; I don't think I'll be able to find longer
   stretches of time for mlabwrap for at least a week (and I'd of course also
   like to do some hacking again rather than more 'adminstrative' stuff like
   writing wiki stuff and emails etc. as I've been mostly doing of late).

Aargh - 3:15am. I really need to learn to be more concise in my emails...

night,

'as