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

Robert Kern robert.kern@gmail....
Thu Mar 29 08:58:21 CDT 2007


Alexander Schmolck wrote:

> 1.a. source code and svn organization
> '''''''''''''''''''''''''''''''''''''
> 
> In an email some time ago Robert Kern proposed the following directory
> structure for scikits:
> 
>       branches/
>       tags/
>       trunk/
>         mlabwrap/
>           setup.py
>           scikits/
>             __init__.py
>             mlabwrap/
>               __init__.py
> 
> 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?
> 
>       mlabwrap/
>         branches/
>         tags/
>         trunk/
>           setup.py
>           scikits/
>             __init__.py
>             mlabwrap/
>               __init__.py
>       some_other_scikit/
>          branches/
>          ...
> 
> 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.

branches/ and tags/ directories can be shared between projects. There's nothing
special about a branch or a tag in SVN; they are just copies. Just make sure you
name your branches and tags appropriately (mlabwrap-1.0, etc.). I would like all
of the scikits to be under one trunk, though, for conveniently grabbing the
current source of all of the scikits without also grabbing every branch and tag.
Branches and tags take little space on the server, but in checkouts, there would
be a tremendous amount of duplication.

> 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):
> 
>       mlabwrap/
>           setup.py
>           scikits/
>             __init__.py
>             README.txt # etc.

This should be one level up.

>             mlabraw.py # dummy importing mlabwrap/mlabraw, for backwards comp.

This shouldn't be here. I'd just put it into the toplevel mlabwrap/ directory
and not install it. Just have it there for people to use if they need backwards
compatibility.

>             mlabwrap/
>               __init__.py
>               -> awmstools.py
>               -> awmsmeta.py

This seems appropriate.

>               mlabwraw.cpp
>             test/
>               test_mlabwrap.py # etc.

This directory should move into mlabwrap/scikits/mlabwrap/ or even mlabwrap/.

> 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.
>               
> Comments? 
> 
> 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.

Leave scikits/__init__.py empty. Do what you like with
scikits/mlabwrap/__init__.py . For a package as small as yours, importing
everything from mlabwrap.py is reasonable. Then people will only have to import
scikits.mlabwrap instead of scikits.mlabwrap.mlabwrap .

> 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.

We need setuptools to handle the scikits namespace package. Does your extension
module use numpy? If so it should also use numpy.distutils. Just make sure to
import setuptools first.

  import setuptools
  from numpy.distutils.core import setup
  ...

-- 
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


More information about the Scipy-dev mailing list