A few of us have been discussing this MultiSiteDev<http://informatics.gpcnetwork.org/trac/Project/wiki/MultiSiteDev> process in various media from off-list email to phone to google hangouts.
I've been working in a collection of suggestions from Alex. Alex, I had another go at it in response to your version (21) . Where I had written " tests should tell a story; don't use names like 'foo' and 'bar'." you asked how. So I elaborated with a link to a new page: As explained in StoryTellingAndTestCases<http://informatics.gpcnetwork.org/trac/Project/wiki/StoryTellingAndTestCases>, tests should tell a story; don't use names like 'foo' and 'bar'. Along those lines, I re-worked the discussion of tasks and dependencies to use actual examples from the heron_load code (load_epic_dimensions and such) rather than `modify_this`. I added a couple diagrams too. You had a detailed paver question; I added an answer: * Question: are the only files that paver imports the ones specified in pavement.py? If so, does this mean that if an ETL module is in its own subdirectory, pavement.py needs to be updated so that the new scripts will be recognized? * That's one option. A couple others: * Use paver -f nifty_tasks.py nifty_task1 rather than referencing pavement.py implicitly. * Put a pavement.py in the ETL module subdirectory and use that. * Factor out any parts of heron_load/pavement.py that you want to re-use. (Yes, nifty_tasks might as well be foo or bar; I couldn't think of a story.) -- Dan ________________________________ From: Dan Connolly Sent: Tuesday, February 18, 2014 2:56 PM To: [email protected] Subject: multi-site shared HERON ETL development and version control One of the things that has come up at each of the sites we have visited is the possibility of shared development of the HERON source code. We set up an AWS instance that hosts the code, and we're working out a MultiSiteDev<http://informatics.gpcnetwork.org/trac/Project/wiki/MultiSiteDev> process for interested developers to participate... -- Dan
