On Thu, May 24, 2012 at 4:12 PM, Travis Oliphant <
teoli...@gmail.com> wrote:
> Here is a brief (but not necessarily inclusive list):
>
> NumPy, SciPy, Matplotlib, IPython, Scikits-Learn, Scikits-statsmodels, Pandas, scikits-image, SymPy, Cython.
>
My original mental list was set up in layers, with python/numpy at the
foundation, then ipython, scipy, matplotlib and sympy for a 'core'
system (basically at the level of matlab, more or less), and adding
Cython, Mayavi, pandas, statsmodels, sklearn, skimage, pytables and
NetwrokX for the whole enchilada.
Put another way, your list + Mayavi, PyTables, NetworkX. Which I
agree, are all the most specialized of the bunch (and mayavi brings in
complex dependencies).
> The point of this meta-package would be to create a concrete release number that is tied to specific releases of the other packages and give us a name to talk about the group of packages as a whole (when citing, etc.).
>
> The meta-package would have recommendations for documentation, continuous integration, and possibly even some utilities that made it easier to see the projects as a coherent group.
>
I really would like this meta-package project to include fairly
specific guidelines on things like packaging, documentation layout,
etc. Once this is in place, we can make it easier for end users to
access unified docs, provide integrated help in IPython with direct
links to example notebooks, etc.
In particular, I'm now convinced that we (the scientific community)
*must* plan for packaging solutions that bypass/ignore distutils as
needed. David C has done enormous work on this front, but he was
never really able to gain any traction on python-dev, partly because
that group simply doesn't have our problems (such as how to link a
library against the fortran compiler of some supercomputing vendor).
I think our energies are better spent on solving this problem well and
for us, than on trying any further to convince the authors of
distutils to think about massive c++/Fortran extensions they've never
encountered.
Specifically, I'd like to move towards fairly strict and predictable
(because by being predictable they enable automation) guidelines on:
- docstrings (format, naming conventions, etc). We're already doing
reasonably well here with the numpy standard.
- documentation layout, formatting and installation. In particular,
standalone examples that can be found by IPython in a search and
brought to the user for direct execution in the easiest way possible
(notebooks that also produce scripts work very well for this).
- packaging: bento or whatever it is. I don't know exactly what the
current situation is on this front, all I want is for us to forget
about what Python does by default and come up with a solution of our
own that is robust and easy to use for users with extension code, and
that allows easily the installation of pre-compiled binaries in
non-root/non-admin scenarios.
Something like this will obviously have to evolve organically over
time, but I think that if we have a common view of this problem, we
can find a way to provide to end users a more coherent and integrated
view of the tools, without the individual projects losing much
autonomy and independence.
My take on this is to move in our core projects (and hopefully thus
set a standard for others to follow) towards a 'federation' model,
where the individual projects retain most of their independence but
they do give a little bit up by accepting common standards on a few
fronts. In return, they'll gain predictability, better reuse of
common solutions, and I'm convinced, much greater impact in the long
run (because we'll become more attractive to end users).
> We need a name for this package. I am proposing the name Sciome. I would love to hear other ideas.
I've been racking my brain over this without much success, but know
I'm terrible at naming things... Onyx is my current favorite (short,
has a y in it... as I said, I'm awful at names)
Cheers,
f