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

[konsolebox]

On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny <mgorny@g.o> wrote:
> 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.

I had to ask help from #gentoo-dev-help in order to properly
understand slot operators since I haven't become too familiar with
them so sorry for the late reply.  (Thanks to desultory and _AxS_).

Here I find it that we could just follow the simple AND/OR rule
against every condition from left to right, and the interpreter would
just do fine.  A user may create insensible rules just like how one
could create meaningless codes in C, but that won't stop the compiler
from compiling the code, just like how this would not prevent the
package manager from interpreting it.  We're also free to detect
ambiguous rules if we want to, and warn the user, or just disallow it
completely.  But it's still optional and wouldn't yield a difference
to a stable operation.

Examples:

dev-foo/bar:={:1.3= :1.4= :1.5=} OR dev-foo/bar(:= {:1.3= :1.4=
:1.5=}) renders := being an "any" operator meaningless since the
condition requires {:1.3= :1.4= :1.5=} to also be true.  It looks
insensible, but it's still algorithmically correct, and can be
interpreted by the package manager.

dev-foo/bar(:* :=) renders :* meaningless since := restricts any
installed runtime dependency's slot and subslot to be currently
available.  It's still algorithmically correct.

dev-foo/bar{:* :=} renders := meaningless since :* would already be
true, if it becomes false, := would still be false anyway. But it's
still algorithmically correct.  In many ways, the rule doesn't make
sense at all since virtually is just boils down to be just about
dev-foo/bar, but it's not an issue that would stop the implementation
of the interpreter.  And, it's also not something that would
jeopardize how the package manager operates.

dev-foo/bar:={:1.3 :1.4 :1.5} OR dev-foo/bar(:= {:1.3 :1.4 :1.5})
implies that the currently installed package's slot and subslot should
be available and that the version of the slot should be 1.3, 1.4, or
1.5.  The interpreter could read that condition checking from left to
right easily.  Is the currently installed package's slot and subslot
currently available?  If no, this condition renders false and the
currently installed package is invalid.  If yes, we follow the next
condition. Is the slot version any of 1.3, 1.4, or 1.5?  If yes, then
that condition yields true.

If this condition fails with the currently installed package, we then
check it against the available packages where the meaning of the =
operator is ignored to see if we can do a rebuild.

> 4. Do we allow different ranges per slots?

Seems possible like {:>=1.3 :<=1.5}.  Comparing subslots is also just
about grouping where in x/y, x is the major and y is the minor.  Major
versions are compared first, and minor versions are only compared if
major versions are equal.

I hope I understand you correctly.

If you're talking about combining ranges of versions with slots, then
yes it's possible.  You just check every condition independently.
It's pretty simple.

> How do we combine various order of data?

I need specific example/detail on that, or perhaps I already have that
answered above.

>>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.

And if we allow every type of condition to be independent, it would
make things easier for everybody.

>
>>
>>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.

I think that would only apply to older versions of Portage that would
not recognize loose arrangement of conditions.  Can you give a
specific variant where would this become an issue?

> 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.

It's quite the opposite.

Before that 'simple validation', parsing would come first (unless
parsing comes along with (the only) validation itself), and parsing
itself [with/without the validation] has already become difficult due
to many conditions that one should come or could come before/after
another.  If every condition would just be elements with different
classes, it would be easier to do a validation.  You'll just need a
single loop with case statements for that, rather than have a tree of
if conditions.

If there's another validation stage that's necessary to do after
parsing, the same holds true for it: just one single loop, and no
check if an element follows one after another.  Checking whether stuff
are repeated is still doable (if it still becomes necessary).

I also hope you're not after grep-ability.  If not, just ignore this.
Grep/regex scanning itself is slow, and is a bit of a hack to me,
especially if it's used in parsing.  Not that I'm saying it's a bad
solution for doing validations, but it shouldn't be something to rely
upon when judging this.

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

I'm sorry but I'm not sure what you mean there.  I hope you can give an example.

>>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.

I actually don't like adding them myself.  It complicates the interpreter.

-- 
konsolebox