Re: How can Blends techniques be adapted to NeuroDebian
sorry for the long delay - I could write some excuses but this would steal
you additional time. :-)
On Sun, Aug 26, 2012 at 06:00:18PM +0200, Michael Hanke wrote:
> > So lets discuss this along these line. Does this fit your proposal and
> > what database would you suggest?
> I'd say let's aim for JSON-based storage -- that is simple, and is
> supported all over the place (incl. web-stuff, and Python). Actually, if
> you already have the per-package information in a Python-dict,
> generating json should be as simple as:
JSON sounds reasonable.
> >>> import json
> >>> data_in_json_format = json.dumps(dict_with_all_the_info)
> JSON goes well with DBs like couchdb (also frequently used and
> _schema-free_, but I'm not a DB expert...). In terms of implementation
> roadmap, I'd say:
> 1. It would be useful to have a dump of all relevant information in a
> JSON text file.
> 2. I'd try to use that and rebuild neuro.debian.net on top of that. And
> it would also help to split the current blends pages script to be
> able to generate the static HTML pages from the content of that JSON
> 3. Once we have that done, we know that we have a working and
> comprehensive data structure. At this point we can put it into a DB
> and create a more dynamic system.
May be we could even spare this step if 1.+2. work out as sufficient.
> It prefer a step-wise approach as it reduces the complexity of the
> problem and automatically structures it (and resulting code) into: data
> aggregation, storage, and retrieval/use. The resulting overhead should
> be minimal and we can have 95% of the desired goals at the end of step
> 2) already.
Also ACK. However, I just learned that my data structures lead to
xyz is not JSON serializable.
errors when trying json.dumps(xyz). The reason is that json.dumps
obviosely can not deal with the Python class structure I invented but
rather needs a set of dictionarys and lists. I will try to fix this by
rewriting the code accordingly however, I realised that I somehow seem
to reach the limit of SVN because I tend to do such coding frequently
when beeing offline and I have some larger chunk of uncommited code for
several changed on my local disk - may be it is time to switch to Git
(and I know you will most probably applause this change ;-)).
In my next mail (which I do not intend to "hide" in this thread) I will
discuss the steps in this direction.