Andreas Tille <andr...@an3as.eu> writes:
> On Tue, Apr 10, 2018 at 10:10:39AM +0200, Ole Streicher wrote:
>> >> 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?
>
> $ git clone https://ole.ath.cx/blends/
> Klone nach 'blends' ...
> fatal: repository 'https://ole.ath.cx/blends/' not found

My wording was easy to misunderstand. I mean:

$ firefox https://ole.ath.cx/blends/

and then check what you read ;-)

>> > 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 ;-)
>
> I confirm that I understood that it is possible to do this.  However, I
> can not imagine that whatever kind of diff between tags will be used
> this is faster than just reading a json file.

It is not faster; it is probably just not much slower.

> In addition I would need to "fake commit" pre-version control data
> into Git (yes, there were releases of Debian Med before I started
> using SVN).  These are now simply stored in json that's aggregating
> the data I want to display[1].

That is ofcourse a good argument, and also maybe the blends class cannot
read all the really old data.

> I admit this json is of different nature and could be used in connection
> with any different method to obtain the Git-based data.  I'm just
> afraid about changing something that is *really* rarely used and simply
> works just for the reason to make it more elegant.

Sure. I am however not sure whether this is true for generating the
changelog entry. Maybe I just add this to blends-gen-control.

BTW, are you happy with the UDD support? Or do you think we need more
here?

Cheers

Ole

Reply via email to