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

[Michał Górny]

Dnia 8 listopada 2016 09:17:11 CET, konsolebox <konsolebox@×××××.com> napisał(a):
>On Tue, Nov 8, 2016 at 3:09 PM, konsolebox <konsolebox@×××××.com>
>wrote:
>> 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.
>
>I should also add that we can allow slots and repositories in the
>expressions:
>
>dev-foo/bar{:1.3 :1.4 :1.5}  ## Solves "A. Range dependencies vs
>slotting"

I'm not sure about this. Slots are kinda special, especially with regard to slot operators. Problems I see:

1. := binds to slot of newest version matching the spec. How does this work with your spec?

2. Should we allow using := on some of the listed slots? What would happen?

3. It's asymmetric since we can't use an AND variant.

4. Do we allow different ranges per slots? How do we combine various order of data?

>dev-foo/bar(:1.6 {::local ::devel})  ## Especially useful in
>/etc/portage/package.{keywords,mask}

Repository deps are not covered by PMS, so that's out of scope. Though if the other lands,I see no problem with Portage implementing this one as well.

>
>Along with it, we should also drop the strict order of the slot,
>version, and repo expressions (just change it to "recommended").  It
>makes things more flexible and makes it easier for the parser to be
>implemented.

Problems:

1. This could result in fairly ambiguous variants with some syntaxes purposes.

2. This makes 'simple validation' harder. Strict order makes it possible to write a simple regular expression that validates that are elements are in place and correct, and are not repeated.

3. Do we allow multiple occurrences of the same type of element? I'm specifically thinking of multiple disjoint USE dependency blocks.

>
>Arithmetic ranges on the other hand should only be in the form of
>being "inclusive" in both ends, and not exclusive in any.  Not only is
>it simpler; it is also easier to parse.  There's also no need to use
>special grouping operators like {}.  E.g. 1.3..1.5.  Grouping is only
>necessary if the form would cause other possible conflicts, where in
>that case (1.3..1.5) and {1.3..1.5} should just be the same, unless
>there would be more added expressions in the group.

I'd say that arithmetic ranges are redundant if we do version ranges.


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