All the Perl that's Practical to Extract and Report
use Perl Log In
hanekomu (8123)
(email not shown publicly)
http://hanekomu.at/blog/
AOL IM: hanekomu (Add Buddy, Send Message)
Go (Baduk) player and Perl hacker.
Module-Changes
There has been some discussion about a machine-readable Changes file.
I'm maintaining a few distributions myself and have phases of making some changes to several distributions. Opening the Changes file, copying a few lines, inserting the current date and time and so on gets tedious.
I wanted to have a command-line tool with which to interact with Changes files. Also the Changes file should be machine-readable. So I wrote Module-Changes. I've chosen YAML for the format, although this is by no means mandatory - it's easy to write a new parser or formatter for your format of choice. Integration of new parsers, formatters etc. is something I still have to work on, though.
Some see YAML as a "failed format", but enough people (me included) find it useful and easy to read for both humans and machines, so that's what I've chosen as the default format. Even so, we need to agree on a YAML schema - that is, the layout of the Changes file.
This is not set in stone, it's more of a proposal. I'm hoping for a discussion of what people like or don't like in the current version, and what they would like to see in future versions.
--Larry Wall in doio.c from the perl source code
Change YAML syntax? (Score:1)
Re: (Score:1)
Format of Changes.yml (Score:1)
What I came up with is a stream of yaml docs (separated by '---'), each containing a hash with info about that version. The reason to use a stream of separate docs is to cut back on indentation ("chrome"). So we only have one indentation level for the lists which means we can easily correct the format if somebody forgets to put the two spaces before the '- ' list token.
Below is an example of how a Changes.yml could loo
Re: (Score:1)
I've seen your proposal and also thought about it.
It seems a bit too detailed. Also I don't think that splitting the structure into different YAML streams for the sake of indentation is ideal. I don't mind indentation - after all, it's supposed to be machine-readable.
If you really want a human-readable version as well, just have the YAML in Changes.yml and run:
changes -f Changes.yml -ff >ChangesBy the way, more updates are coming. I've simplified the YAML somewhat (less indentation!) and added a
Re: (Score:1)
Sorry, but if you keep it that way, it won't get much ground. First and foremost, it should be conveniently human-writable, everything else comes afterwards. Because if you can't write it conveniently as a human, people won't use the format and stay with "unreadable" formats for Changes files. Having the Changes file generated from Changes.yml adds complexity to the build process which is somewhat acceptable if it's easily (1 line in Makefile.PL) autom
Re: (Score:1)
I'm stupid. I just saw Module::Changes::Parser::Free [cpan.org] , which does just what I proposed. Thank you for anticipating my complaints :))