rootpy currently has submodules for interfacing with matplotlib, numpy, and pytables. The numpy interface is basically a copy of root_numpy: https://github.com/piti118/root_numpy.
Instead, what if rootpy only held the core essential stuff but we had the optional packages:
and root_X for interfacing with some other technology X, etc.
root_numpy could continue to stand on its own, owned by @piti118 and forked under rootpy or moved to the rootpy collaboration and forked by @piti118. I have no preference either way. That would be up to @piti118.
root_matplotlib would depend on rootpy since it requires rootpy's Hist API.
root_tables would depend on root_numpy and rootpy.
root_numpy stands on its own.
Some of the numpy-related code in rootpy could be moved to root_numpy (filling hists with numpy arrays, etc).
Then I think the various capabilities of rootpy are made more explicit and the user can choose to install whatever "plugins" they choose.
@piti118, @cdeil, @pwaller, @ekfriis, @jklukas what do you think?
I kind of want root_numpy to do one thing and do it well: just convert root data in root file to numpy fast.
I myself don't use PyROOT anymore. I'm replacing my analysis stack with python libraries and only use root_numpy as a bridge away from ROOT. I think keeping root_numpy very modular like this is a better idea.
@piti118 exactly. No changes would be requested of root_numpy. It could effectively stand on its own like it does already. It would only be "recognized" as an "official" plugin of rootpy. Although we do have some new code for for filling ROOT hists with numpy arrays and @cdeil is working on code to convert ROOT hists into numpy arrays. Would you be interested in placing this in root_numpy instead of rootpy?
You mean TH1F to numpy? That one makes sense to be in root_numpy.
I could also make root_numpy part of rootpy organisation too. But... I'm afraid that there is gonna be a name clash with the fork.
Yes, TH[1|2|3][C|S|I|F|D] to a numpy array as well as filling any of these with a numpy ndarray
rootpy's fork can be deleted
I have pulled everything right?
yes, it should be fine to just delete rootpy's fork
If others agree on the proposal above, then I can begin separating out the matplotlib and pytables specific stuff into their own packages. I'll wait for comments.
I deleted root_numpy under rootpy
Hmm... it said I don't have admin right. May be the right thing to do is another way around ... delete mine and keep rootpy's then fork it back to my account?
sorry, I just gave you admin rights on rootpy. You should be able to transfer root_numpy to rootpy and then fork it back to your account. I've never done this before so hopefully all goes smoothly...
nice, I see root_numpy under rootpy now
Done. Transfer and refork. http://rootpy.github.com/root_numpy/ works too.
Great! Thanks @piti118. You have admin rights on all of rootpy so can continue to push directly to root_numpy there.
I don't know if making root_matplotlib and root_tables standalone is an improvement.
More modular is good.
On the other hand it's also good to make things simple for the end-user.
And I guess more repos means more complicated installation and less integrated documentation and possibly version mismatches between rootpy and the other projects.
I think I'd prefer having one repo that contains sub-packages that have pytables and matplotlib as optional dependencies to make things as simple for the end-user as possible. This is not a strong opinion though, obviously @ndawe feel free to modularize rootpy if you think it gives a better structure.
@ndawe, can I ask what your current feelings are on this matter? Is it still a goal? Have we reached a reasonable medium?
I'm happy with the current state of things: basic numpy functionality in root_numpy and loosely coupled subpackages in rootpy for HDF5 and matplotlib support (and hopefully in the near future Roo[Fit|Stats]).