Now that GSoC is over, there are some things that should be accomplished in the Tor Weather codebase soon to reach "deployment":
1. remove local copy of OnionPy and replace with real thing 2. (ideally automated) front-end tests 3. ensure production and Vagrant setup are as close as possible 4. tests with dump/copy of live database
Less important, but still Very Nice To Have:
5. more unit-test coverage would be nice too 6. nicer-looking HTML
I do not have enough spare cycles to accomplish all these things myself. I will commit to rapidly reviewing/merging to the "develop" branch any pull-requests. If any of the above sounds interesting, please follow-up here (or in #tor-dev).
Thanks, meejah
Hi!
I've been meaning to catch you to talk about tor-weather. Sadly, spare cycles are rare for me, too.
On 08/30/2014 12:55 AM, meejah wrote:
Now that GSoC is over, there are some things that should be accomplished in the Tor Weather codebase soon to reach "deployment":
1. remove local copy of OnionPy and replace with real thing
That means we need to get OnionPy packaged and into wheezy-backports, no?
Best, Luke
Lukas Erlacher tor@lerlacher.de writes:
1. remove local copy of OnionPy and replace with real thing
That means we need to get OnionPy packaged and into wheezy-backports, no?
Medium-term, yes. We can use it as a (git) submodule of tor-weather meantime (e.g. until we're reasonably sure the API is fine).
Cool, I thought of that, too. Sounds like a workable thing to do. I will keep the master branch of OnionPy clean and working (modulo bugs) so you should be fine just using that. I'll set up a way to run the tor-weather tests before I push a new version of OnionPy.
Would you like me to fork tor-weather and do the integration of OnionPy?
Best, Luke
Alright, here's what I've done -
1. Review onionoo_wrapper and merge changes back into OnionPy
lucyd essentially forked OnionPy for tor-weather. I merged the changes he made back into OnionPy: - More detailed exceptions - lucyd changed the class wrappers for OnionOO documents (summary, details, bandwidth, etc.) to use dicts instead of object properties. That's neat, but dicts are designed and implemented for dynamic data structures. I believe that it's better to leave these as properties. - 79 char line length - turned functions in utilities into class methods - added the test suite
I have released OnionPy 0.2 with these changes. Thanks to lucyd and everyone else who helped with this!
2. Integrate OnionPy into tor-weather
- add the OnionPy repo as a submodule - rewrite weatherapp/management/commands/rundaily.py to use OnionPy
I pushed this to my tor-weather fork. (https://github.com/duk3luk3/tor-weather)
It's nowhere near done, and I'm confused what the files weatherapp/rewrite_daily.py and weatherapp/rewrite_hourly.py are doing. rewrite_daily.py has basically the same code as weatherapp/management/commands/rundaily.py, but rewrite_hourly is all alone.
Any hints?
Best, Luke
Lukas Erlacher tor@lerlacher.de writes:
- Review onionoo_wrapper and merge changes back into OnionPy
Awesome, that all sounds good. I agree about the properties vs. dicts.
It's nowhere near done, and I'm confused what the files weatherapp/rewrite_daily.py and weatherapp/rewrite_hourly.py are doing. rewrite_daily.py has basically the same code as weatherapp/management/commands/rundaily.py, but rewrite_hourly is all alone.
The "new stuff" is the rewite_(hourly|daily) scripts, which will be run from cron (although I don't think Vagrant has this config yet). I do not believe the others are required; more for reference? Ultimately, they'll get deleted.
Thanks for tackling this, I'll take a look at your branch as time allows, hopefully later this week.
Cheers, meejah
-
Lukas Erlacher -
meejah