[Slackbuilds-users] requirements in README files

[J]

Quoting Jan Herrygers <janherrygers at dommel.be>:

> Op dinsdag 10 juli 2012 12:44:58 schreef J:
>> Thanks for clearing that up, I now see where you're coming from. And I
>> believe you're misunderstanding; please all me an attempt to clarify:
>
> You want to build a tool that simplifies building a dependency graph. You
> already stated that this "simplificating tool" shouldn't be and won't be a
> replacement for reading the READme.

That's wrong and right - wrong about "want to", because I've already  
done, but there are so many variations to the formatting - even among  
those using the "This requires" format - that it's increasingly  
non-trivial to handle... and as other emails in this thread have  
indicated, I am not the only one who'd find this useful. right about  
the rest, because it will only attempt to parse requirements if the  
user has not chosen to skip viewing the README file. otherwise, it  
will care about requirements exactly as the slackbuild itself would  
have if the user were interacting with it completely manually - ie not  
at all.

> Let me think a little outside the box. Bear with me, or skip this section,
> whatever you like.

I have read virtually ever word in this thread :)

> Perhaps a tool, some variation of less, more, vim, Emacs, cat,... , can be
> written in which you simply highlight the name of a dependency, and the text
> that you highlighted is added to a dependency list.
> When you are finished reading a readme, you move on to the readme  
> for the next
> package on the dependency list. And so on ad infinitum (or until you have
> finished your list).
>
> That way you aren't dependent on any formatting being present, but you still
> get a nice dependency tree. (I have no idea how one would build such a
> program, but I'm optimistic about the feasability and feature set of the
> mythical deptree tool I described above.)

This is a neat idea - but it still requires a parser. And once the  
parsing is done, then it's a matter of actually running the  
slackbuilds, so we're back to the doing the same exact manual steps  
over and over and over again - and that's stupid, in my opinion.  
personally, where I find myself doing the same manual steps over and  
over, I automate. so, we have the parser, and we have the repeated  
steps. ergo, my tool. it makes sense to me, anyway.

> Op dinsdag 10 juli 2012 12:44:58 schreef J:
>> So, again: my concern is strictly limited to formatting, and only for
>> actual hard and fast requirements, not optionals. This represents a
>> minor formatting change *at worst*. And that, I believe, requires no
>> change to the testing currently done by admins.
>
> Back in the box again.
> A recommendation on how to list dependencies in a readme would be nice. But
> asking the admins to either edit the recommended format into every readme, or
> to give you write access to the repo, is a lot to ask. I wouldn't count on a
> standard that gets enforced to the point that it can be parsed with awk,
> regexes, or something like that.
>
> But publishing a recommendation doesn't hurt, and it can be  
> beneficial for the
> human reader too.
> I woul like a list delimited by newlines and/or tabs (perhaps multiple
> spaces?) That would IMHO be much more readable than separated by "," or "and"
> delimiters.
> Those who want to follow the recommendation, can do so, and those who don't
> want to, can keep doing what it is that they do want to do.

not ideal of course, but this would be a start. couple things, then,  
given this (not arguments, but discussion to possibly move it forward):
1. how does such a recommendation get communicated to slackbuild  
maintainers? admins out there, would you be willing to publish such a  
recommendation on slackbuilds.org? after all, if it weren't stated  
there, it wouldn't exactly be worth much.
2. formatting - newline/tab/multiple-space delimited, any of these is  
easily parseable, so I would be happy with any of these options or  
anything else that is easily parsed. but I do think it makes sense to  
stick with the currently most popular format - otherwise we end up  
with even more different types of formatting than we already have.

off to work for me.
thanks.
J