<bobthecow>
ddfreyne: hrm. if you're not using rainbow, who is?
<bobthecow>
oh. rubocop uses rainbow.
<bobthecow>
cri uses colored.
alerante has quit [Remote host closed the connection]
<bobthecow>
okay. effing core mixins.
<bobthecow>
colored mixes in a private method called color into String.
<bobthecow>
rainbow, by default, mixes in a public method called color.
<bobthecow>
they do different things.
<bobthecow>
as of 2.0, rainbow won't mix in by default.
<bobthecow>
which will be awesome.
<bobthecow>
you know, cri could solve this by switching to rainbow ;)
alerante has joined #nanoc
alerante has quit [Remote host closed the connection]
alerante has joined #nanoc
alerante has quit [Remote host closed the connection]
alerante has joined #nanoc
alerante has quit [Changing host]
alerante has joined #nanoc
alerante has quit [Remote host closed the connection]
Jutah_ has joined #nanoc
louquillio has quit [Ping timeout: 240 seconds]
Jutah has quit [Ping timeout: 240 seconds]
antognolli has quit [Ping timeout: 240 seconds]
Jutah_ is now known as Jutah
louquillio has joined #nanoc
antognolli has joined #nanoc
alerante has joined #nanoc
alerante has quit [Remote host closed the connection]
ics has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ics has joined #nanoc
number-six has quit [*.net *.split]
bobthecow has quit [*.net *.split]
number-six has joined #nanoc
bobthecow has joined #nanoc
number-six has quit [Excess Flood]
number-six has joined #nanoc
alerante has joined #nanoc
alerante has quit [Ping timeout: 240 seconds]
ics has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
relix has joined #nanoc
alerante has joined #nanoc
alerante has quit [Ping timeout: 246 seconds]
<ddfreyne>
bobthecow: I've had issues with that before... hmmm.
<ddfreyne>
bobthecow: Gah, problem with argument_groups...
<ddfreyne>
bobthecow: Imagine having 'rm -f -- -blah' to delete the file '-blah'. The -- stops option parsing and starts a new argument group. Currently, cri only creates a new argument group if the previous one is not empty. So the argument groups in this case will be [ [ '-blah' ] ] which makes sense.
<ddfreyne>
However, `git checkout -- blah` <- argument_groups will be [ [ 'blah' ] ], not [ [], [ 'blah' ] ]
<bobthecow>
ddfreyne: i don't actually know of any prior art for that.
<bobthecow>
i can think of programs that use -- to disambiguate positional arguments, and i can think of programs that use -- to stop processing flags.
<bobthecow>
git add, for example.
<bobthecow>
echo "foo" > -whot; git add -whot
<bobthecow>
it says to use `git add -- -whot`
<bobthecow>
but `git checkout` lets you use flags anywhere before the file arguments.
tantalum has joined #nanoc
iosdiof has joined #nanoc
<bobthecow>
ddfreyne: release v2.5.0!
<bobthecow>
you know you want to!
<ddfreyne>
bobthecow: Hmm.
<ddfreyne>
bobthecow: Not until this problem is resolved in a reasonable way (either by code, or by explaining things)
<ddfreyne>
bobthecow: atm, `git checkout -- blah` will not work (it will be treated the same as `git checkout blah`)
<bobthecow>
i think dropping that empty? condition like i mentioned is the ideal solution.
<ddfreyne>
hmmm.
<bobthecow>
what's your concern with that?
<bobthecow>
*most* people only need it for the first style (stopping parsing options flags)
<bobthecow>
the few people who need it for the second style can deal with the hassles that come with it.
<bobthecow>
i don't think there's a good way to magically make it work for both stopping options parsing and separating argument groups without making the dev do a little work defining what she wants.
<ddfreyne>
bobthecow: How would you use -- to stop option parsing in e.g. `git checkout -- -blah` ?
<ddfreyne>
It won't work and I don't see a way to work around that easily...
<bobthecow>
that's what i'm saying... git handles it themselves because it's an edge case.
<bobthecow>
git add -blah
<bobthecow>
git add -- -blah
<bobthecow>
^ that acts like you'd expect.
<ddfreyne>
bobthecow: How about not having argument_groups, but rather an option to get the list of arguments *including* -- ?
<bobthecow>
because in git add, -- has no special argument group meaning.
<ddfreyne>
raw_arguments or so.
<bobthecow>
but then we're back to what i think is the most common case: needing to split arguments on those --
<bobthecow>
and now devs have to do it by hand.
<bobthecow>
having access to the raw arguments wouldn't be a bad thing, but i still think there's value for argument groups.
<bobthecow>
that said, i can write my own wrapper in my base class if i have access to raw arguments.
<ddfreyne>
bobthecow: My issue with argument_groups right now is that any solution will be opinionated, and it will not cater to all users
<ddfreyne>
I'd rather provide something more low-level, with the possibility for users to treat the data they want it
<bobthecow>
works for me.
<bobthecow>
i think going back to the earlier idea of an array-ish for arguments would be better.
<bobthecow>
then you could have methods on it for getting groups.
<bobthecow>
methods for getting raw.
<bobthecow>
etc.
<ddfreyne>
bobthecow: Yeah, ArgumentArray, and cri would provide #raw and allow users to extend that (by e.g. adding #grouped or so)
<bobthecow>
fwiw, my needs would be best met by something like this: args :field, values: 0..-1, files: 1..-1
<bobthecow>
i almost wrote that.
<ddfreyne>
what is field, values and files in this case?
<bobthecow>
but without a good heuristic the partition between values and files would have to be explicit.
<bobthecow>
argument names.
<bobthecow>
three positional arguments, two of which are arrays.
<ddfreyne>
Right
<bobthecow>
but it needs the heuristic for implied grouping to be fully awesome.
<bobthecow>
some of my commands have a signature like this:
ics has joined #nanoc
<bobthecow>
args :field, :value, files: 1..-1
<bobthecow>
others:
<bobthecow>
args :field, files: 1..-1
<bobthecow>
right now i've got one DSL extension for dealing with the value/values/nil middle chunk, but it's a bit ugly.
<ddfreyne>
bobthecow: `if (i = args.index('--'))` <- this will never work in cri atm, because -- is never part of args. With ArgumentArray#raw this could work though
<bobthecow>
i know. that was there as a placeholder.
<bobthecow>
while i was waiting for the groups issue to be resolved.
<ddfreyne>
the `args` there could be replaced by `args.raw` and it'd work, given ArgumentsArray#raw is implemented
<bobthecow>
yeah.
<bobthecow>
for cp, the positional args dsl call would be
<bobthecow>
args from: 1..-1, :to
ics has quit [Ping timeout: 252 seconds]
<bobthecow>
for git checkout:
<bobthecow>
args ref: 0..1, files: 0..1
<bobthecow>
0..-1 rather
<bobthecow>
again, not super useful without the heuristic for splitting it.
<ddfreyne>
bobthecow: Maybe being able to assign a custom ArgumentArray subclass to each command would be nice.
<bobthecow>
maybe, but that might be a bit overkill, right?
<ddfreyne>
e.g. CheckoutArgumentArray with #branch and #files
<bobthecow>
yeah, i was going to make the #args dsl method implement named methods for each of its argument/groups
<bobthecow>
so if you called `args from: 1..-1, :to` it would make a #from that returns arguments[0..-2] and a #to that returns arguments.last
<bobthecow>
but if there's an ArgumentArray, putting those methods on the argument class would be even better.
<bobthecow>
arguments.from, arguments.to
<ddfreyne>
But the #from and #to from one command can be different on another command
<bobthecow>
right. so you only mix in the ones that apply.
ics has joined #nanoc
<bobthecow>
anyway, i didn't implement the dsl method because it's not as useful for anything besides super basic positional argument lists.
<bobthecow>
as soon as you need logic to guess (is this argument a file?) it stops being awesome.
<ddfreyne>
So do you agree being able to assign custom ArgumentArray subclasses is useful?
<bobthecow>
maybe use a struct-like constructor for ArgumentArray so that for normal use you don't have to subclass?
<ddfreyne>
Not sure what you mean there
<ddfreyne>
you can always pass Class.new(ArgumentArray) etc
<ddfreyne>
Hm.
<ddfreyne>
ArgumentArray subclasses are probably a bit silly because you can define this stuff in the command dsl anyway
<ddfreyne>
OK, so just ArgumentArray which implements #raw.
<bobthecow>
meaning, if argumentarray constructor could take something that indicated what positions were what.
<bobthecow>
for me, the weirdest thing i have to deal with isn't the split between values and files, it's the fact that the first argument is always popped off before splitting.
<bobthecow>
so with argument groups, it was coming out of the first group.
<ddfreyne>
bobthecow: What about args 0 => :field, 1 => :blah, 2..-1 => :otherstuff, and then you'd be able to do arguments[:blah] and get the 1st arg?
<bobthecow>
that's what i was saying, but with a prettier dsl :P
<bobthecow>
having it accept a symbol as an index is weird if it's an array-ish though.
<ddfreyne>
Yeah, maybe the other way around
<bobthecow>
args :field, :blah, otherstuff: 0..-1
<ddfreyne>
Still, that is a separate nice feature that is not necessarily related to argument_groups
<bobthecow>
the ranges like that make more sense to me.
<bobthecow>
true.
<bobthecow>
related but not so much.
<ddfreyne>
Step 1: ArgumentArray with #raw
<bobthecow>
just related in that it makes things weird when you're trying to extract explicit positional arguments out of the groups.
<bobthecow>
those ones are easy to model using a dsl call.
<bobthecow>
the complicated one is: <command> <field> <value> [<value> ...] <file> [<file> ...]
<bobthecow>
and that's only 20% of my commands.
<ddfreyne>
bobthecow: But the basic ones are easy to model using a custom CommandRunner anyway (say, FieldFilesCommandRunner and FieldValueFilesCommandRunner or so)
<ddfreyne>
(or mixin, if you want)
<ddfreyne>
So it seems to me that getting hold of the “raw” arguments (with --) definitely seems worth it, because it gives enough power to disambiguate arguments
<ddfreyne>
And whether you want a DSL for assigning symbolic names to arguments or not is then up to you, extending cri with what you need
<ddfreyne>
bobthecow: ATM I feel that anything more than ArgumentsArray#raw is overkill, but I'd like to play around with symbolic names for arguments in the nanoc CLI and see how I can write something that is generally usable so that it fits most people's use cases
<ddfreyne>
bobthecow: I like cri right now, because it has zero bloat and I want to keep it that way
<bobthecow>
ddfreyne: i agree. #raw would get me what i need right now.
<bobthecow>
i don't think having #groups would hurt though.
relix has joined #nanoc
<bobthecow>
with empty groups where `command -- arg`.argument.groups == [[], ['arg']]