[Slackbuilds-users] requirements in README files

[J]

Another thing which has been mentioned a few times, and which I have  
considered off and on myself, is a fork of the repo. There are several  
reasons I have not pursued this idea; it constitutes an amount of work  
which would keep me busy doing that for an unrealistic amount of time,  
or it requires a parser able to grok our random requirement listings,  
and I'm back to square one.  I don't like the inelegant, brute-force  
nature of it, either. All that said, I do think it would be  
realistically possible, feasible, and perhaps even a bit sane, with  
more than one person working on it. And once the main body of work is  
completed, then it's on to 14.0, and once that is completely,  
significantly less work would be required moving forward. until  
$VERSION++, but that can be dealt with when it's reached.

So, all that said. There are a number of replies from people who would  
like to see this happen. If there is anyone who would be interested in  
forking the repo, then building a system to achieve this, please send  
an email to me personally. In the end, all the work involved might be  
easier.

J


Quoting J <j at dawnrazor.net>:

> 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
>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/