wiki:BrainStorming

Context Navigation

Last modified 3 weeks ago

Brainstorming

Merging with Pyrocko and general project and architecture changes

Pyrocko: http://emolch.github.com/pyrocko/

General opinion: Let's do it!

Things that Pyrocko has that ObsPy does not

The snuffler
Cake module (ray tracer on a spherical Earth) and associated modules for Earth models, plots, ...
Pile module (Fast iteration over many data files - also used by snuffler) and associated modules
Some additional geodesic functions.
A moment tensor module. ObsPy can only plot moment tensors.
... ?

Proposed changes to ObsPy (in no particular order)

Merge some commonly used modules (obspy.core, signal, waveform readers, data aquisition)
- Pros:
  - Ease svn installation.
    - (Lion) Can IMHO be solved with better documentation.
    - (Sebastian) I suggest to make a single setup.py in the top level directory of ObsPy. The subpackages to be installed can then easily be controlled by some command line options to setup.py. This would make the whole structure more convenient. When I download a Python package, after unpacking, I expect to see a setup.py, a README, and probably something like a docs directory. With this approach, no merging of modules would be needed. Only some work on the installation scripts.
      - (Robert) done ;)
  - Some functionality is guaranteed and most people install all modules anyways.
- Cons:
  - obspy.core module would needs to be compiled.
    - (Robert) IMHO an absolute "no go" - core should be installable without any compiler otherwise we will loose new "customers" at this very first stage
  - More dependencies for obspy.core - so far the policy was to have as little dependencies as possible. The only one is numpy.

Move to github
- Pros:
  - git has more functionality and things like branches and tagging would become much easier.
  - Nice webtools on github.
  - Other people can (as long as they have a github account) simply work on a certain part of ObsPy and then send a pull request to us. This might actually get us more externally contributed code.
  - Many large and small Python projects are hosted on github. De facto standard hosting for python projects?
- Cons:
  - No anonymous tickets anymore
    - (Robert) personally no problem with that: (1) *no* ticket spam == more time for development, (2) people also subscribe to the mailing list to ask question - github is pretty similar
      - (Lion) There are some solutions to this problem, if desired: http://www.georf.de/723/anonyme-tickets-in-github/
  - More complicated to use and conceptually understand than svn. -> Might avert some newer programmers.
    - (Sebastian) Doing simple things is still simple with Git. We can make a one page summary of basic Git usage in the wiki.
    - (Robert) SVN checkout is still possible (even a write access but that seem to be a bit buggy)
  - We have to move everything to github.
    - (Lion) No problem for source tree, except for the branches and tags. Not sure how to handle those. More work for the wiki and especially the tickets. What happens with all the old references between commits and tickets? How to handle the documentation?
      - (Sebastian) To move tickets from Trac to GitHub: https://github.com/adamcik/github-trac-ticket-import. (Probably doesn't solve the references problem.)

New project name
- Pros:
  - Clear seperation of "before merging with Pyrocko" and "after merging"
  - Would equalize ObsPy and Pyrocko.
- Cons:
  - Giving up the ObsPy "trademark" and the fact that many people know it.
  - (Sebastian) I can live with the name "ObsPy", what matters is functionality and not the name. Using a new name would IMO only make sense when combined with a kind of restart because a new name (even if it would only be e.g. ObsPy2) would make clear that there might be some incompatibilities with older versions.
  - (Robert) I guess we have a common agreement that if we slowly migrate via deprecations and so on that we should keep the name (so this point is IMHO solved) - but if we ever plan to switch completely to Python 3.x we should make such harsh step and rename it too e.g. "ObsPy2" - again I don't care to much about the name if we have such "restart"

"restart" of the project
- Pros:
  - We can change a lot of things without worrying about the users.
  - Restart the project with the gained experience would result in cleaner code
- Cons:
  - A huge amount of work.
    - (Lion)... for a benefit that could probably also be gained through incremental updates.
      - (Sebastian) "restart" must not mean "rewrite" (that would really be a crazy idea). But a major new version, which breaks some backward compatibility, could make things easier.
      - (Robert) as most developers preferred a slow migration I tend to stick with the herd - however again if we at any point plan to switch completely to Python 3.x I see no reason for not doing this step
  - It would probably take a while before we are back at the level where we are now.

Consistent naming scheme
- Pro:
  - Its consistent and would also make growing ObsPy easier.
- Cons:
  - Breaks compatibility. Might need deprecated alternatives for a while.
- Proposed schemes:
  - ?

No camel case functions/methods
- Pros:
  - Python itself sticks to it
  - PEP8 recommendation.
  - More readable especially with verbose function/method names.
    - (Robert) this!
  - Pyrocko does it.
- Cons:
  - Someone has to do it.
  - Breaks compatibility. Needs deprecated alternatives at least for commonly used functions.

Merge a lot of modules to clear the module jungle
- Pros:
  - Reduces the already rather large, and it will likely grow, module count.
  - Less modules to care about during releases
  - Could be used to group functionality
  - Should in theory be easier for users to understand
- Cons:
  - Breaks the modularity at least to a certain degree
  - Quite some work

Give up Python 2.5 support
- Pros:
  - Added functionality: http://docs.python.org/whatsnew/2.6.html
    - (Robert) I miss especially setter decorators which cleans up the code base
  - Some workaround will no longer be necessary.
    - (Robert) resulting into performance gain in never versions
  - (Robert) Fewer Python versions to maintain - which consumes developing/packaging/testing time
- Cons:
  - Will no longer work with Python 2.5.
    - (Lion) Which major Linux distributions still ship with Python < 2.6?
    - (Marcus) Redhat EL 5 ships with python 2.4 and is supported until 2017. Because of 2.4 it wasn't a target platform at any time (luckily).

Technical merging questions/ideas/... assuming we will integrate Pyrocko into ObsPy

How to start? Simply in the branches or in seperate modules?
(Lion) I would propose to first (assuming we will do it) move ObsPy to github and then merge both. This would retain the history of Pyrocko and all changes because Pyrocko is already on github.
- (Sebastian) Agree!
- (Robert) Ok I'll take care about that once we all agree on moving to GitHub?
Where to put stuff?
- Snuffler: trunk/apps
- Cake and associated modules: new module obspy.simulation (or obspy.pyrocko_simulation)
- Moment tensor class: obspy.core? Maybe also hook it up with the beachball plotting methods and the Momenttensor handling in the events.
  - (Robert) this has to move from obspy.imaging into obspy.core.event anyway
- Geodesic function: Merge with trunk/obspy.core/obspy/core/util/geodetics.py?
  - (Robert) BTW is this namespace correct - I know I checked it in - but it feels somehow wrong :/
- Pile: Not really sure. Maybe also obspy.core?

(Robert) Maybe Sebastian can provide some more insight what would be the best approach - I know its hard to find a starting point - Pyrocko is quite big :) - but if you can somehow give some kind of milestone ...

Download in other formats:

Plain Text