[SciPy-dev] mlabwrap scikit [Was: Re: scikits project]

Alexander Schmolck a.schmolck@gmx....
Wed Mar 28 22:13:28 CDT 2007

[Second attempt to move this to scipy-dev, this time using the right email
account; for those who have no idea what mlabwrap is about: it's a python to matlab
bridge currently on the move from sourceforge to scipy's emerging scikits


First, it's great that mlabwrap has found a new home at scipy.org, big thanks
to everyone involved. 

I'm afraid that I'm still not quite up to speed on all
infrastructural issues -- I've not used subversion before and I haven't
completely grokked the scipy infrastructure yet (although I've been trying to
read up, especially on svn) and I'm a bit puzzled by some things (see below),
so please excuse if some of what follows sounds a bit clueless.

In order to bring the mlabwrap project forward, there are three things I'd
like to achieve in the immediate future (by end of next week):

1. Resolve remaining infrastructural questions
2. Bring out mlabwrap-1.0 final
3. Discuss a roadmap and feature requirements for mlabwrap 2.0

So let's start out with 1. :

"Jarrod Millman" <millman@berkeley.edu> writes:
> Hey,
> Jeff got everything setup and I tested it out.  Everything looks good
> (Thanks Jeff and Robert!).
> I checked in mlabwrap v1.0b:
> https://projects.scipy.org/scipy/scikits/browser/trunk/mlabwrap
> And then since Jeff installed the rest macro; I added
> [[ReST(/trunk/mlabwrap/README.txt)]]
> which Trac renders like this:
> https://projects.scipy.org/scipy/scikits/wiki/MlabWrap
> I also moved the discussion about proxy objects from the NIPY site:
> https://projects.scipy.org/scipy/scikits/wiki/MlabProxyObjects
> Hopefully everyone has access to the scikits subversion repository
> now.  If not, please try and get access ASAP. 

Shouldn't having a svn account mean that I'd be able to succesfully log in to
the trac interface at
<https://projects.scipy.org/scipy/scikits/browser/trunk/mlabwrap> using the
same account? I can't either use the AlexanderSchmolck login I created on
scipy.org, nor the POP3/SVN login a.schmolck@gmail.com[1]  I received an email
from webmin@scipy.org on Friday[3]; however I *can* commit to the repository
using svn (I've sent an email to webmin@scipy.org, but haven't heard anything

Another thing I've been wondering about is whether it would be easy to import
the existing CVS repository into svn? I've fiddled around a little bit
with cvs2svn and on first sight it looks like it migh work OK. Loosing the
project history wouln't be too tragic (and I can just try to get the sf staff
to upload the old CVS repository on the sf page, so it's publically available
somewhere), but if we can just import the existing repository without too much
of a hassle, I think this might be the best option.

Before doing anything with the CVS repository, I'd first manually adapt the
directory structure, though, bringing us to

1.a. source code and svn organization

In an email some time ago Robert Kern proposed the following directory
structure for scikits:


The current directory structure misses the scikits/ dir and the second
mlabwrap/ dir; instead it has mlabwrap.py at top-level (as well as the utility
libraries awmstools.py and awmsmeta.py and the c++-extension mlabraw.cpp).
Independent of scikits conventions, it seems that making mlabwrap a package
and stuffing everything it needs inside (i.e. the utility libs and mlabraw)
rather than polluting the toplevel module-namespace seems desirable

I assume this question reflects my svn-newbie status, but why doesn't the
scikits structure look something like this, given that as I understand it
scikits are meant to be essentially independent (and hence independely
versioned) projects under a common namespace?


It somehow seems to me that tags and branches should apply to individual
projects and that one could still do convenient releases and svn-checkouts of
scikits/ as a whole by using e.g. svn:externals to the individual projects. As
I said, I'm not really knowledgable about svn, but I'd like to understand the
logic a bit better, because I'm also trying to work out what to do about the
awmsmeta.py and awmstools.py stuff, which isn't really a part of mlabwrap as
such. I see three ways of dealing with the dependency on the utility modules:

D1. Drop it and copy-and-paste the needed bits into mlabwrap.py (certainly
    possible, only a few functions are needed; OTOH it seems a bit ugly)
D2. Rely on cheeseshop (but I don't have the impression that it is equally
    acceptable and painless for a python module to download and install
    dependencies as it is for a CTAN module)
D3. Stuff copies  into mlabwrap/ and do a relative import

D3. seems most attractive to me at the moment but one would still have to
figure out where the VC of awmstools.py and awmsmeta.py would "live"; I
thought it would be cleanest if they were included as svn:externals and not
directly part of the mlabwrap svn tree, so I thought maybe something like
this (ignoring the question of where branches/ trunk/ and tags/ go exactly):

            README.txt # etc.
            mlabraw.py # dummy importing mlabwrap/mlabraw, for backwards comp.
              -> awmstools.py
              -> awmsmeta.py
              test_mlabwrap.py # etc.

I also assume we want a branch for the 1.0.x version, a tag for the 1.0 release
(when it's ready) and that development of the next version will continue in
the trunk.

Also are there any strong feelings/established procedures concerning
__init__.py? The generic name is somewhat inconvient in various contexts (e.g.
buffer switching im emacs) so I thought about making __init__.py a dummy
importing ./_mlabwrap.py or so.

OK, sorry this is getting so long, on to 

2. bringing out mlabwrap-1.0 final:

Apart from the question what the directory structure should look like, the
only issue that I'm currently aware of is that there appears to be a problem
with `setup.py` automatically finding out about the matlab version under
windows; if no one steps up to do some windows testing I'm also willing to
apply some fix I assume will work and release as is (windows users might have
to set MATLAB_VERSION etc. in setup.py by hand if it doesn't, which isn't
*that* terrible). Actually, one more thing: distutils vs. scipy distutils vs.
setuptools -- which one should mlabwrap-1.0 final use? I'm only really
fully familiar with the first one.

Finally point 3, the road-map:

I'd like to get some idea what is felt as needed for the next version of
mlabwrap (let's say 2), by when (e.g. because it would be really handy for
NIPY; how important is e.g. that 'proxy.a.b = c' works as expected?) and who
is interested on working on specific parts (like the move to ctypes). Also
what python and matlab versions should mlabwrap 2 have to support?

How should changes affecting backwards compatibility best be handled (maybe
allowing getting v1 default behavior with something like `from mlabwrap.v1
import mlab`?)?

I've put up some notes concerning mlabwrap development and design issues at
<http://www.scipy.org/MlabWrap>, corrections, additions and feedback (using
either the wiki page itself or scipy-dev) are highly welcome.

Sorry for the relative long silence -- apart from hacking on the next version,
writing up my thoughts and wikifying took *far* longer than I would have
thought, especially since it's only personal note-quality rather than
something polished. I hope it's at least partly intelligible and useful.



[1]  Are those two account logins meant to be different or is this just
     because I was too dumb to notify Jeff Strunk of my newly created scipy.org
     account in time? BTW unless there's some convention that the svn login
     should be an email address, I'd rather just have a.schmolck (sans
     gmail.com), if it's something that's easy to change.

More information about the Scipy-dev mailing list