Re: [gentoo-dev] RFC: Future EAPI version operator changes

[Michał Górny]

Dnia 8 listopada 2016 08:09:55 CET, konsolebox <konsolebox@×××××.com> napisał(a):
>On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@g.o> wrote:
>> Hi, everyone.
>>
>> Following my previous RFC wrt version operator problems, I'd like to
>> start the second part of the discussion: how to improve version
>> operators in a Future EAPI?
>>
>> I've collected various ideas on operator changes on a wiki page [1].
>> I've tried to stay open-minded and cover every possibility, even
>though
>> I doubt some of them would be even considered.
>>
>> I should warn you that some of the solutions are interlinked to each
>> other, and you probably need to look through the whole page first
>> before starting to construct an opinion. For example, specific
>> solutions to most of the problems depend on whether we enable version
>> ranges and in which form.
>>
>> I think we should start by loosely discussing the various ideas
>> on the wiki page. Feel free to also point out any missing ideas
>> or remarks that would be useful there.
>>
>> So, what are your comments?
>>
>> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes
>>
>> --
>> Best regards,
>> Michał Górny
>> <http://dev.gentoo.org/~mgorny/>
>
>I also like the idea of moving the operator as it's more consistent
>and opens new doors to other solutions.
>
>As for the use of operator & and |, they're quite good, but I'd prefer
>the use of Gmail's style where expressions placed in () are processed
>with AND, and expressions placed inside {} are processed with OR:
>
>dev-foo/bar[>=1.3&<1.5]        dev-foo/bar(>=1.3 <1.5)
>dev-foo/bar[>=1.3&<1.5&!=1.4.1]        dev-foo/bar(>=1.3 <1.5 !=1.4.1)
>dev-foo/bar[<1.1|>=1.5]        dev-foo/bar{<1.1 >=1.5}
>dev-foo/bar[=1.1*|=1.3*|>=1.5]        dev-foo/bar{=1.1* =1.3* >=1.5}
>
>I find it more readable.  The former looks too compressed.

Two points here:

1. I really had no idea Gmail has anything like that, and I suspect a lot of developers don't expect things to work that way either. I'm a programmer though, so infix && and || are entirely obvious to me.

2. I don't think we are going to allow whitespace inside it. Currently dependency specifications can be tokenized on whitespace (except for special handling for groups). Allowing whitespace inside ranges breaks that.

Furthermore, if we allows whitespace inside ranges, we should probably consider allowing any whitespace in package dependency specifications, to improve readability. This in turn can open a few cans of worms.

-- 
Best regards,
Michał Górny (by phone)