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

[Alexander Schmolck]

First, sorry for letting this one drag, I've still got a backlog of other
mlabwrap related TODOs and there are other things I need to get done urgently,
but I should have dealt with this earlier.

"Brian Hawthorne" <brian.lee.hawthorne at gmail.com> writes:

> On 5/2/07, Jarrod Millman <millman at berkeley.edu > wrote:
>>
>> I have been thinking about what the priorities should be for the next
>> stable release of mlabwrap.  My only personal priority is to have it become
>> a scikit release.  

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.

It seems to me that with the change of name inherent in the move to scikits we
have a visible change and unavoidable code breakage anyway (because at least
the import statements in user code will need changing) and thus a good
opportunity to introduce a clean break, if that's required to improve the
capabilities of mlabwrap. 

In the meantime, with (pre-scikits) mlabwrap 1.0, there is already something
viable and stable in the open that people who want to use mlabwrap to
interface to matlab can use (and I think scikits.mlabwrap should make
transition easy by offering an compatibility layer, if required).

For those who are willing to live on the bleeding edge there's always svn and
we can also make development release-eggs (BTW, I think we should really move
the svn repository to scipy.org soon, if possible).

Introducing incompatible changes piecemeal into scikits.mlabwrap without
causing user-annoyance and confusion seems less manageable to me in
comparison.

Having said this, I do agree with the priorities outlined below, and I think
we should come up with some reasonable project time-table, so that we're
working towards concrete milestones -- I'll append some things on my mind
below.


>> I know that it is still somewhat unclear exactly what is required to be a
>> scikit, but my 3 priorities are:
>> 1) use setuptools namespace packages.

Essentially done, but there are some related issues (where ``testing.py``
should go should go and getting the version.py thing to work properly).

>> 2) remove support for Numeric and Numarray.

Done.

>> 3) use NumPy testing.

Mostly done. The only thing that needs to be reviewed IMO, *if* we do want to
make a release, is if we really want to have testing.py in the scikits
namespace (i.e. ``scikits.testing``). For an official release, I suggest
not including testing (making test_mlabwrap import it conditionally), since

a) it's not clear to me that we should put something other than mlabwrap into
   scikits/, without further discussion
b) it's just there to ease test-driven development and is not needed to run
   the tests in batch-mode
c) it's pretty pre-alpha

Adding to your list, here are the things currently on my mind

4) Move svn to scipy.org (as mentioned above)
5) Get the info on <http://projects.scipy.org/scipy/scikits> sorted out; this
   should indirectly resolve all remaining mlabwrawp issues pertaining to all
   scikits (things like version.py, the use of numpy.distuils and tract etc.;
   I'll try to send an email to the list about this in a few hours)
6) Maintenance release of mlabwrap-1.0.1 which solves the LD_LIBRARY_PATH
   problem (unless we do a scikits.mlabwrap 1.0 release)
7) Make interactive, test driven development convenient by augmenting
   numpy.testing as required
8) Commit the hybrid-proxing stuff, so people can give it a spin



>> Maybe the best way to proceed would be to quickly get these 3 issues
>> resolved and then release a stable release of mlabwrap.  It should probably
>> be called 1.1 or 1.5.
>
>
> That seems like a good incremental step. I believe the three issues above
> are taken care of. I created a 1.1 branch to represent the release.
> Alexander, can you think of anything else that needs to be done for these
> three things before making the 1.1 release? If not, I'll go ahead and post
> an egg to PyPI.

I'm all for releasing an egg, but as I said, I'd perfer such an egg to be
clearly marked as a development release unless there is a compelling reason we
need an official 1.1 release.


cheers,

'as