reorganize the folder structure

[belevtsoff]

Reorganize subpackages:

• make cluster, features, io, etc. as seperate modules that can be accessed directly from spikesort package.
• create a separate package spike_sort.stats and put statistic tests there
• reorganization of tests may also be required

comform to numpy.distutils conventions:

• use SpikeSort/spike_sort/ instead of SpikeSort/src (maybe)
• create setup.py for every subpackage and place it in the corresponding folder

here's an rather general overview: http://www.euroscipy.org/file/3708?vid=download

[belevtsoff]

updated description to include numpy.distutils

[btel]

I disagree with numpy.distutils conventions:

• many python packages put the packages in src. It definitely makes sense for spike_sort to use src, because we have multiple top level packages (spike_sort, spike_analysis, spike_beans,
• having separate setup.py for each package is a maintenance nightmare
• I like the overview, but I could not find the above conventions there.

My suggestion is

setup.py
src
  spike_beans
  spike_analysis
  spike_sort
    evaluate
       __init__.py
       ...
    features
    extract
    cluster
    io
    ui

[belevtsoff]

many python packages put the packages in src. It definitely makes sense for spike_sort to use src, because we have multiple top level packages (spike_sort, spike_analysis, spike_beans,

ok, this is why I put 'maybe' in the end. I agree with suggested tree structure

having separate setup.py for each package is a maintenance nightmare

how is this a nightmare? I find it even more structured. For example, if one needs to add some extension in C or fortran to, say spike_sort, then only corresponding setup.py have to be modified. Hence, root/src/subpackage/setup.py contains only relevant information about the subpackage, like mentioned above, while root/setup.py only contains information about author, license, paths, available subpackages, etc. Having a single setup.py for everything will turn it into an unreadable mess as the project grows, I think. Numpy's setup.py for example, looks clean, having that they have lots of subpackages and external code.

I like the overview, but I could not find the above conventions there.

right, it'll move it outside of the numpy block

[belevtsoff]

actually, the overview mentions the recursive setup.py approach. See NUMPY.DISTUTILS slide

[btel]

They say (my emphasis):

Enable “recursive” setup.py for complex, deeply nested packages

I think the structure of spike_sort is still not that complex. I do not like the idea that you need to edit multiple scripts when you want to change the installation method. Especially when the packages are dependent on each other (as it is the case in spike_sort).