On Tue, Nov 8, 2016 at 6:28 PM, Michał Górny <mgo...@gentoo.org> wrote:
> Dnia 8 listopada 2016 08:09:55 CET, konsolebox <konsole...@gmail.com>
> napisał(a):
>>On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgo...@gentoo.org> 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.
Yes I understand that it's new to most people that's why I'm not
really getting my hopes up on this idea. But I honestly see it as an
implementation that's easier to use in many ways. The only difference
is how people would get used to it. There had become a lot of
rules/operators in Portage where people had to refer to the manual in
order to understand them, and the difference between () and {} is just
a simple thing.
> 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.
I got a bit lost there. I hope you can give some elaborate/technical
examples about it.
--
konsolebox
