Andreas Tille <andr...@an3as.eu> writes: >> However, tasks_diff may also benefit from a blends >> Python package, and it could make the handling much easier (no json), as >> if the blends package is in git with a standard tagging: >> >> * git worktree could check out the latest debian/<version> tag to some >> temporary dir >> >> * one can create a blends.Blend object from that dir >> >> * one can create a blends.Blend object from the actual dir >> >> * compare them, write out, and you are done. > > That's surely an option for the changelog creation. But the json files > also enable creating statistics using this script. Its just a > hack and not documented (if I only had the time to do this) but just > parsing a set of json files is probably way more sensible than to do > your algorithm over and over again for all available tags.
Another reason to create a separare python3-blends package... that script should be convertible to use it. >> If you like, I could try that as next step; then I would however just >> create a "python3-blends" package (to not interfer with the >> python3-debian package). > > May be a python3-blends package assembling (and documenting!) that kind > of tools (and put them on a solid technical base rather than hackish > scripts) would make sense. That is the main idea of the rewrite. Check out https://ole.ath.cx/blends/ which is generated from the blends-gen-dev source. Does it fit your needs in terms of functionality and documentation? > But I think, sticking to the approach to store the dependency data in > some sensible way (not necessarily inside the source package) is > reasonable if you want to look quickly at historic data. We already have git, so creating a function that returns a `blends.Blend` object based on some git tag (rep. Debian version) is straightforward with `git worktree` and also (since the blends source packages are rather small) quick. And has the advantage that you don't need to maintain an additional json file. You can just generate it on the fly ;-) Cheers Ole