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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Jan Chren (rindeal)]

First of all thank you for the research and wish you a good luck in
making the changes happen.


## Reordering to PACKAGE OP VERSION

<cat/pkg> [<operator> <version>] [:<slot>]

is more sane than

<cat/pkg> [:<slot>] [<operator> <version>]

even though it's not so "hierarchically correct".

Thus instead of writing

dev-foo/bar:4===4.1

one would write

dev-foo/bar==4.1*:4=

which is nicely readable.

But in case the box brackets notation gets incorporated (as in Exheres),

<cat/pkg> [:<slot>] [[<operator> <version>]]

is the way to go.


## Version ranges

dev-foo/bar:0[(>=2 && <4) || (>=6 && <10)][baz?]

looks the most promising to me as it allows to include and exclude any
number of ranges.


## Things not included

### Comments/annotations

Currently, there is no way to put inline comments to *DEPEND, IUSE,
..., thus the only supported way is to put the comments above the
specification and somehow tell the reader what part of the
specification is the comment about. For 3-4 deps it's acceptable, for
20+ it's insane and thus no one does it, losing valuable information
about the reasoning by doing so.

Mu current workaround is:

DEPEND_A=(
   # comment
   "cat/pkg..."
   "|| ("
      # comment
      "cat/foo"
      "cat/bar"
   ")"
)
DEPEND="${DEPEND_A[*]}"


### Logical operators for groups

#### OR

Currently there is no way to specify:

foo||bar? (
  cat/pkg
)

and one has to copy&paste a lot:

foo? (
  cat/pkg
)
bar? (
  cat/pkg
)

#### AND

AND can be specified via nested groups:

foo? (
  bar? (
    cat/pkg
  )
)

but this syntax is verbose and not explicit.

foo&&bar? (
  cat/pkg
)

would be much more readable.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Sun, 6 Nov 2016 18:05:39 +0100
"Jan Chren (rindeal)" <dev.rindeal@gmail.com> wrote:

> ## Things not included
> 
> ### Comments/annotations
[...]
> ### Logical operators for groups
[...]

This is off-topic to *version operators*. Please don't divert the
discussion. If you want to pursue these, please open a separate 'Future
EAPI' bugs (if there are none open for them already) and track it there.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Alon Bar-Lev]

On 6 November 2016 at 12:52, Michał Górny <mgorny@gentoo.org> wrote:
> Hi, everyone.

<snip>

> So, what are your comments?

Hi,

Just my 2 cents...
I kinda love the prefix nature of the expressions which is consistent
and easier to parse.
Using infix only for versions and leaving all the rest prefix will
create abnormality.

Regards,
Alon

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Mon, 7 Nov 2016 22:47:24 +0200
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> On 6 November 2016 at 12:52, Michał Górny <mgorny@gentoo.org> wrote:
> > Hi, everyone.  
> 
> <snip>
> 
> > So, what are your comments?  
> 
> Hi,
> 
> Just my 2 cents...
> I kinda love the prefix nature of the expressions which is consistent
> and easier to parse.
> Using infix only for versions and leaving all the rest prefix will
> create abnormality.

What abnormality exactly? Where do you see prefix elsewhere in package
dependencies?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Brian Dolbec]

On Mon, 7 Nov 2016 22:47:24 +0200
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> On 6 November 2016 at 12:52, Michał Górny <mgorny@gentoo.org> wrote:
> > Hi, everyone.  
> 
> <snip>
> 
> > So, what are your comments?  
> 
> Hi,
> 
> Just my 2 cents...
> I kinda love the prefix nature of the expressions which is consistent
> and easier to parse.
> Using infix only for versions and leaving all the rest prefix will
> create abnormality.
> 
> Regards,
> Alon
> 

But the main problem with it is that most upstream requirements.txt,
etc.,... all use the infix method.  And I hate to say it, but more and
more so-called "package management" systems (mostly language specific
ones) all use that method.  So transitioning to that, should make
package maintenance easier.  Possibly even have some automation tools
to check them during version bumps, etc...

-- 
Brian Dolbec <dolsen>

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 617 bytes --]

>>>>> On Mon, 7 Nov 2016, Brian Dolbec wrote:

> But the main problem with it is that most upstream requirements.txt,
> etc.,... all use the infix method. And I hate to say it, but more
> and more so-called "package management" systems (mostly language
> specific ones) all use that method. So transitioning to that, should
> make package maintenance easier. Possibly even have some automation
> tools to check them during version bumps, etc...

But certainly any such automated tools would do a complete parsing of
the grammar? Because then conversion from infix to prefix notation or
vice versa is trivial.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

On Mon, 7 Nov 2016 22:47:24 +0200
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> Just my 2 cents...
> I kinda love the prefix nature of the expressions which is consistent
> and easier to parse.
> Using infix only for versions and leaving all the rest prefix will
> create abnormality.

You know what? Let me break all your dreams.

So, the way I see it: someone back in the ol' days thought: let's do
version syntax different than everyone else, so we look cool. And let's
use some smart name for it, even though it makes no sense
in the context. And as all bad things in Gentoo do, suddenly many
developers were thinking the same mistaken idea.

So let's keep it short:

1. This is NOT *prefix notation*. This is some kind of sick weirdo
prefix-suffix notation.

2. The suggested solution is *suffix*, NOT infix. Like everything else
in the package dependency spec.

3. If everything else were 'prefix' like this, then package
dependencies would look like >:[?app-foo/bar-1.2.3-1-gtk.

4. We are *not* comparing package name against the version. We are
applying various restrictions to a dependency.

5. Dependency groups are actually using prefix notation. Still, I don't
see any benefit from reversing package dependency specs and doing
[gtk]3:>3.4.0-app-foo/bar. Though it's probably still better than what
we're doing right now since we can at least sanely split version
and category.

So, sorry, the syntax does not make you look cool, it doesn't make
sense and is inconsistent with everything else.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[konsolebox]

On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@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.

-- 
konsolebox

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 2027 bytes --]

On 08/11/16 07:09, konsolebox wrote:
> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@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.
>
Ewww, WTF should we use Google as a (bad) example?! And "bracketising"
rather than explicit operators is bound to cause confusion and errors ...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[konsolebox]

On Tue, Nov 8, 2016 at 3:49 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> On 08/11/16 07:09, konsolebox wrote:
>> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@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.
>>
> Ewww, WTF should we use Google as a (bad) example?!

I don't care if it's from Google or not, and you shouldn't as well.
Grow up.  It's got nothing to do with the solution.

> And "bracketising"
> rather than explicit operators is bound to cause confusion

Subjective, and depends on the person.  I quickly adapted to it.

> and errors ...

What errors?

-- 
konsolebox

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

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On 08/11/16 08:03, konsolebox wrote:
> On Tue, Nov 8, 2016 at 3:49 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
>>
>> Ewww, WTF should we use Google as a (bad) example?!
> I don't care if it's from Google or not, and you shouldn't as well.
> Grow up.  It's got nothing to do with the solution.
I'll defer to mgorny as policy maker on this one .. and such rebukes are
wholly unnecessary (although prolific) in Gentoo ..
>> And "bracketising"
>> rather than explicit operators is bound to cause confusion
> Subjective, and depends on the person.  I quickly adapted to it.
>
>> and errors ...
> What errors?
>
Just wait and see ...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[konsolebox]

On Tue, Nov 8, 2016 at 3:09 PM, konsolebox <konsolebox@gmail.com> wrote:
> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@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.

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"
dev-foo/bar(:1.6 {::local ::devel})  ## Especially useful in
/etc/portage/package.{keywords,mask}

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.

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.

-- 
konsolebox

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

[Michał Górny]

Dnia 8 listopada 2016 09:17:11 CET, konsolebox <konsolebox@gmail.com> napisał(a):
>On Tue, Nov 8, 2016 at 3:09 PM, konsolebox <konsolebox@gmail.com>
>wrote:
>> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@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.
>
>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)

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

[konsolebox]

On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 8 listopada 2016 09:17:11 CET, konsolebox <konsolebox@gmail.com> napisał(a):
>>On Tue, Nov 8, 2016 at 3:09 PM, konsolebox <konsolebox@gmail.com>
>>wrote:
>>> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@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.
>>
>>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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 6816 bytes --]

On Wed, 9 Nov 2016 14:32:33 +0800
konsolebox <konsolebox@gmail.com> wrote:

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

Wrong. It means 'any OR 1.3 OR 1.4 ...'. Making 'any' no longer mean
'any' in this context is confusing.

What about {:1.3/2 :1.3/3 :1.3=}?

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

'any AND newest'? Why would you ever do that? The only purpose for :*
is to disable warnings on missing slot specifications when package has
multiple slots.

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

It's worse than meaningless. It requires the PM to record installed
slot for no reason whatsoever, since you allow it to switch to another
slot anyway.

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

I see a lot of added complexity here, for no benefit whatsoever.

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

Slots are not numbers nor versions. You can't compare them.

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

That's what I was asking for.

> > 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 {>=3.4 :5[foo]} ([bar] <3.7))

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

dev-foo/bar:1===3

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

Yes, I am. In some cases, regexp is the only thing you have
(e.g. in XSD). The major problem with current syntax is that you can't
properly validate restrict="" in XSD because you'd have to
backreference operator.

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

dev-foo/bar[foo][bar]

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[konsolebox]

On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Wed, 9 Nov 2016 14:32:33 +0800
> konsolebox <konsolebox@gmail.com> wrote:
>
>> On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> >>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.
>
> Wrong. It means 'any OR 1.3 OR 1.4 ...'. Making 'any' no longer mean
> 'any' in this context is confusing.

Isn't that 'any AND (1.3 OR 1.4 OR 1.5)'?  Would that make sense to
have it the other way around instead?

And when I wrote that, I already had the idea of AND being the default
control operator, and spaces being optional.

> What about {:1.3/2 :1.3/3 :1.3=}?

Left to right.  If :1.3/2 yields true, then the whole condition is
valid, next is :1.3/3, then last :1.3=.  If all is false, then the
whole condition is false.

>> dev-foo/bar(:* :=) renders :* meaningless since := restricts any
>> installed runtime dependency's slot and subslot to be currently
>> available.  It's still algorithmically correct.
>
> 'any AND newest'? Why would you ever do that? The only purpose for :*
> is to disable warnings on missing slot specifications when package has
> multiple slots.

I hope you're only arguing against the misuse, and not about whether
it's feasible when it comes to the implementation.

But anyway, "newest" is not what's being said in ebuild(5):

":=     Indicates  that  any  slot value is acceptable. In addition,
for runtime dependencies, indicates that the package will break unless
a matching package with slot and sub-slot equal to the slot and
sub-slot of the best installed version at the time the package was
installed is available."

It's all about whether the currently installed runtime dependency's
current slot and sub-slot is available.  := in this case is simply
about checking that, and could only yield true or false.

Like I said I'm still new when it comes to these operators, but kindly
enlighten me so that we would know if := can be used as an independent
conditional expression or not.

Again, I don't agree with the misuse.  I just intend to give an example.

>> 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.
>
> I see a lot of added complexity here, for no benefit whatsoever.

No, it's not complex at all as everything would just be packaged in
one logical code.  I just had to explain detail by detail so I could
prove that it's doable.

The current check-if-some-specific-element-comes-before-or-after-another
which propagates everywhere in every context of every different type
of conditional element being checked makes things more complex.

>> > 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.
>
> Slots are not numbers nor versions. You can't compare them.

Not that I really care about ranges for slots, but can you explain
why?  Is that somehow dependent to a current implementation?

>> > 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 {>=3.4 :5[foo]} ([bar] <3.7))

I'm yet to add opinion on allowing use flags to be used anywhere
besides outside a group and only once.  But that looks doable,
although seems more complicated to implement, or at least heavier,
maybe.  You should also correct that a bit:

dev-foo/bar(:1.6 {>=3.4 (:5 [foo])} ([bar] <3.7))

Also, enclosing [bar] and <3.7 inside () may not be necessary, unless
you'd want <3.7 to only compare against dev-foo/bar[bar] where you'll
have to use {![bar] <3.7}, or introduce a ternary operator like '[bar]
? <3.7 : true', which I think is not yet a necessary feature to
include.

>> >>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?
>
> dev-foo/bar:1===3

Ok, just like everyone has already suggested grouping may be necessary.

dev-foo/bar:1=(==3)

>> > 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.
>
> Yes, I am. In some cases, regexp is the only thing you have
> (e.g. in XSD). The major problem with current syntax is that you can't
> properly validate restrict="" in XSD because you'd have to
> backreference operator.

I don't know XSD, but it's good if we can improve it as well so we can innovate.

>> > 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.
>
> dev-foo/bar[foo][bar]

Again, I never really thought about allowing the [use] block to be
more re-arrangeable in the sense that it can be used more than once
and that it can be allowed inside condition blocks, but so far it
really looks doable, and we could drop the restrictions.  This would
be possible along with having everything changed to independent
conditional elements.

-- 
konsolebox

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 6120 bytes --]

On Wed, 9 Nov 2016 18:17:25 +0800
konsolebox <konsolebox@gmail.com> wrote:

> On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > On Wed, 9 Nov 2016 14:32:33 +0800
> > konsolebox <konsolebox@gmail.com> wrote:
> >> 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.  
> >
> > Wrong. It means 'any OR 1.3 OR 1.4 ...'. Making 'any' no longer mean
> > 'any' in this context is confusing.  
> 
> Isn't that 'any AND (1.3 OR 1.4 OR 1.5)'?  Would that make sense to
> have it the other way around instead?

I'm sorry, I misread that.

> >> dev-foo/bar(:* :=) renders :* meaningless since := restricts any
> >> installed runtime dependency's slot and subslot to be currently
> >> available.  It's still algorithmically correct.  
> >
> > 'any AND newest'? Why would you ever do that? The only purpose for :*
> > is to disable warnings on missing slot specifications when package has
> > multiple slots.  
> 
> I hope you're only arguing against the misuse, and not about whether
> it's feasible when it comes to the implementation.
> 
> But anyway, "newest" is not what's being said in ebuild(5):
> 
> ":=     Indicates  that  any  slot value is acceptable. In addition,
> for runtime dependencies, indicates that the package will break unless
> a matching package with slot and sub-slot equal to the slot and
> sub-slot of the best installed version at the time the package was
> installed is available."

I meant newest installed.

> >> 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.  
> >
> > I see a lot of added complexity here, for no benefit whatsoever.  
> 
> No, it's not complex at all as everything would just be packaged in
> one logical code.  I just had to explain detail by detail so I could
> prove that it's doable.
> 
> The current check-if-some-specific-element-comes-before-or-after-another
> which propagates everywhere in every context of every different type
> of conditional element being checked makes things more complex.

I think you're forgetting the most important point here. Dependency
specifications are not only used to check some installed package for
match. They also need to make it possible to semi-reasonably pull
in additional packages that could be used to satisfy the dependency.

The more complex conditions you allow, the harder the task becomes for
the PM and the slower Portage becomes (because it needs to consider
more variants of a possible solution).

> >> > 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.  
> >
> > Slots are not numbers nor versions. You can't compare them.  
> 
> Not that I really care about ranges for slots, but can you explain
> why?  Is that somehow dependent to a current implementation?

Slots are free-form strings by design. This has its uses, including
named slots ('stable', 'testing'...), subslots representing SONAMEs of
multiple libraries ('liba0-libb4')...

> >> > 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 {>=3.4 :5[foo]} ([bar] <3.7))  
> 
> I'm yet to add opinion on allowing use flags to be used anywhere
> besides outside a group and only once.  But that looks doable,
> although seems more complicated to implement, or at least heavier,
> maybe.  You should also correct that a bit:
> 
> dev-foo/bar(:1.6 {>=3.4 (:5 [foo])} ([bar] <3.7))

Why are you forcing whitespace in some contexts and not in other
contexts? Does this mean the common case would look like:

  dev-foo/bar >= 1.4 :1.6 [bar]

?

> > Yes, I am. In some cases, regexp is the only thing you have
> > (e.g. in XSD). The major problem with current syntax is that you can't
> > properly validate restrict="" in XSD because you'd have to
> > backreference operator.  
> 
> I don't know XSD, but it's good if we can improve it as well so we can innovate.

Err, are you talking Gentoo is supposed to request full FSM to be
included in XML Schema? I honestly doubt standard bodies will seriously
consider that.

> >> > 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.  
> >
> > dev-foo/bar[foo][bar]  
> 
> Again, I never really thought about allowing the [use] block to be
> more re-arrangeable in the sense that it can be used more than once
> and that it can be allowed inside condition blocks, but so far it
> really looks doable, and we could drop the restrictions.  This would
> be possible along with having everything changed to independent
> conditional elements.

'I never really thought' is the core problem. When you want to change
PMS, you really have to think about everything. Otherwise, you end up
with screwups like := in || ().

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[konsolebox]

On Wed, Nov 9, 2016 at 7:12 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> >> dev-foo/bar(:* :=) renders :* meaningless since := restricts any
>> >> installed runtime dependency's slot and subslot to be currently
>> >> available.  It's still algorithmically correct.
>> >
>> > 'any AND newest'? Why would you ever do that? The only purpose for :*
>> > is to disable warnings on missing slot specifications when package has
>> > multiple slots.
>>
>> I hope you're only arguing against the misuse, and not about whether
>> it's feasible when it comes to the implementation.
>>
>> But anyway, "newest" is not what's being said in ebuild(5):
>>
>> ":=     Indicates  that  any  slot value is acceptable. In addition,
>> for runtime dependencies, indicates that the package will break unless
>> a matching package with slot and sub-slot equal to the slot and
>> sub-slot of the best installed version at the time the package was
>> installed is available."
>
> I meant newest installed.

Ok, so do you think := can be used anywhere just like any other
conditional element?

>> >> 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.
>> >
>> > I see a lot of added complexity here, for no benefit whatsoever.
>>
>> No, it's not complex at all as everything would just be packaged in
>> one logical code.  I just had to explain detail by detail so I could
>> prove that it's doable.
>>
>> The current check-if-some-specific-element-comes-before-or-after-another
>> which propagates everywhere in every context of every different type
>> of conditional element being checked makes things more complex.
>
> I think you're forgetting the most important point here. Dependency
> specifications are not only used to check some installed package for
> match. They also need to make it possible to semi-reasonably pull
> in additional packages that could be used to satisfy the dependency.
>
> The more complex conditions you allow, the harder the task becomes for
> the PM and the slower Portage becomes (because it needs to consider
> more variants of a possible solution).

I still need to confirm things in a more technical manner, so I can't
make a reply about that for now.

> Slots are free-form strings by design. This has its uses, including
> named slots ('stable', 'testing'...), subslots representing SONAMEs of
> multiple libraries ('liba0-libb4')...

I see.

>> >> > 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 {>=3.4 :5[foo]} ([bar] <3.7))
>>
>> I'm yet to add opinion on allowing use flags to be used anywhere
>> besides outside a group and only once.  But that looks doable,
>> although seems more complicated to implement, or at least heavier,
>> maybe.  You should also correct that a bit:
>>
>> dev-foo/bar(:1.6 {>=3.4 (:5 [foo])} ([bar] <3.7))
>
> Why are you forcing whitespace in some contexts and not in other
> contexts? Does this mean the common case would look like:
>
>   dev-foo/bar >= 1.4 :1.6 [bar]
>
> ?

Sorry, I misguessed.  I thought you wanted :5 and [foo] to be used
together; that both items should be true.

>> > Yes, I am. In some cases, regexp is the only thing you have
>> > (e.g. in XSD). The major problem with current syntax is that you can't
>> > properly validate restrict="" in XSD because you'd have to
>> > backreference operator.
>>
>> I don't know XSD, but it's good if we can improve it as well so we can innovate.
>
> Err, are you talking Gentoo is supposed to request full FSM to be
> included in XML Schema? I honestly doubt standard bodies will seriously
> consider that.

I see. I can't comment much on that unfortunately.

>> >> > 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.
>> >
>> > dev-foo/bar[foo][bar]
>>
>> Again, I never really thought about allowing the [use] block to be
>> more re-arrangeable in the sense that it can be used more than once
>> and that it can be allowed inside condition blocks, but so far it
>> really looks doable, and we could drop the restrictions.  This would
>> be possible along with having everything changed to independent
>> conditional elements.
>
> 'I never really thought' is the core problem. When you want to change
> PMS, you really have to think about everything. Otherwise, you end up
> with screwups like := in || ().

Well I'm also the type who tries to consider everything, but this was
more of a blind spot, and a little bit of a different context
that you can't think about quickly.

I also just thought that everyone would feel conservative towards it,
so I was just being careful, but I actually like the idea of including
[use] blocks in the change.

-- 
konsolebox

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

[Michał Górny]

Dnia 8 listopada 2016 08:09:55 CET, konsolebox <konsolebox@gmail.com> napisał(a):
>On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@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.

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)

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

[konsolebox]

On Tue, Nov 8, 2016 at 6:28 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 8 listopada 2016 08:09:55 CET, konsolebox <konsolebox@gmail.com> napisał(a):
>>On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@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

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

[Michael Orlitzky]

On 11/06/2016 05:52 AM, Michał Górny wrote:
> 
> 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.
> 
> ...
> 
> So, what are your comments?
> 

I read through the whole thing, and... it's overwhelming. A lot of the
later proposals would be affected by the first one, the reordering of

  >=app-foo/bar-x.y.z

to

  app-foo/bar >= x.y.z

Maybe it makes sense to discuss that first, since it impacts so many of
the rest? In that proposal, the one problem mentioned is that the syntax
would collide with the subslot dependency syntax. For example, right
now, if I want to depend on SLOT=4 of app-foo/bar and I need my package
to rebuild when app-foo/bar changes subslots, then I would use

  app-foo/bar:4=

With the infix change, this becomes a problem if I add an "==" version
operator on the end:

  app-foo/bar:4===4.1

If we're changing everything already, though, can't we adjust the syntax
for the subslot operators? I didn't know that ":4=" was the syntax that
we used to depend on both a slot and a subslot. My first impression is
that it would make more sense to use ":=4", since that can be read as
"slot equals 4", just like ":*" means "slot whatever". It's not a
perfect translation, but it sounds better than ":4=", and ":=4" looks
like a stronger version of ":4", which is accurate.

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

>>>>> On Tue, 8 Nov 2016, Michael Orlitzky wrote:

> [...] In that proposal, the one problem mentioned is that the syntax
> would collide with the subslot dependency syntax. For example, right
> now, if I want to depend on SLOT=4 of app-foo/bar and I need my
> package to rebuild when app-foo/bar changes subslots, then I would
> use

>   app-foo/bar:4=

> With the infix change, this becomes a problem if I add an "=="
> version operator on the end:

>   app-foo/bar:4===4.1

> If we're changing everything already, though, can't we adjust the
> syntax for the subslot operators? I didn't know that ":4=" was the
> syntax that we used to depend on both a slot and a subslot. My first
> impression is that it would make more sense to use ":=4", since that
> can be read as "slot equals 4", just like ":*" means "slot
> whatever". It's not a perfect translation, but it sounds better than
> ":4=", and ":=4" looks like a stronger version of ":4", which is
> accurate.

This wouldn't completely solve it, because we also have a := slot
operator. So =app-foo/bar-4.1:= would become app-foo/bar:==4.1
(or app-foo/bar:===4.1 if we also change = to ==) in the new syntax.

Brackets would help, or some new separator. Pick your poison:

   app-foo/bar:=(=4.1)
   app-foo/bar:=[=4.1]
   app-foo/bar:={=4.1}
   app-foo/bar:=::=4.1
   app-foo/bar:=;=4.1
   app-foo/bar:=@=4.1
   app-foo/bar:=#=4.1
   app-foo/bar:=☺=4.1

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michael Orlitzky]

On 11/08/2016 09:49 AM, Ulrich Mueller wrote:
> 
> This wouldn't completely solve it, because we also have a := slot
> operator.

Oh, duh...


> Brackets would help, or some new separator. Pick your poison:

I would really like to have spaces around the infix operators, but then
we need to separate the dependencies with a delimiter (like a comma).

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

On Tue, 8 Nov 2016 10:39:09 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 11/08/2016 09:49 AM, Ulrich Mueller wrote:
> > 
> > This wouldn't completely solve it, because we also have a := slot
> > operator.  
> 
> Oh, duh...
> 
> 
> > Brackets would help, or some new separator. Pick your poison:  
> 
> I would really like to have spaces around the infix operators, but then
> we need to separate the dependencies with a delimiter (like a comma).

Strictly speaking, we don't have to since the lexing should be
predictable enough. Of course, mistakes like missing version following
the operator would result in curious errors.

The major problem with spaces I see is that it means we end up having
an additional [use] block floating following them.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Michael Orlitzky]

On 11/08/2016 10:47 AM, Michał Górny wrote:
> 
> Strictly speaking, we don't have to since the lexing should be
> predictable enough. Of course, mistakes like missing version following
> the operator would result in curious errors.
> 
> The major problem with spaces I see is that it means we end up having
> an additional [use] block floating following them.
> 

I was also thinking that the logical operators could be infix, and then
you need the commas to avoid precedence issues with the implicit-and,
which is written " ". The [use] blocks could be moved next to the
package name I guess. If we were to rewrite the dependency syntax from
scratch, what would it look like? My first attempt would look something
like,

  DEPEND="dev-lang/perl,
          net-misc/wget || net-misc/curl,
          apache2? ( www-servers/apache[apache2_modules_cgi] >= 2.4 ),
          ssl? (
		!libressl? ( dev-libs/openssl:=0 ),
		libressl? ( dev-libs/libressl:= )
	  )"

The reason I'm entertaining this is because the more operators we add,
the more awkward the prefix notation gets. If we had spaces around the
operators, they wouldn't need to consist of invalid package characters,
and we could do something like,

  DEPEND="app-foo/bar in [1,2]"

to request a version in the closed interval [1,2]. For (half) exclusive
ranges, we could have (1,2), (1,2], and [1,2) -- there's no need to
reinvent that particular wheel. We know that "in" surrounded by spaces
is an operator, and we know the types of its two arguments. With prefix
notation, you'd have

  DEPEND="inapp-foo/bar[1,2]" #fail

There's always ∈, but you still have to figure out what's in the brackets.

It's fun to brainstorm, but there are probably numerous problems with
every syntax I've imagined, and the only way to have a meaningful
discussion about one of them would be to create a reference
implementation and migrate some ebuilds. Retraining hundreds of
developers and users is a high bar to set without being damn sure that
we've got it right.

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

[konsolebox]

On Wed, Nov 9, 2016 at 8:30 AM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 11/08/2016 10:47 AM, Michał Górny wrote:
>>
>> Strictly speaking, we don't have to since the lexing should be
>> predictable enough. Of course, mistakes like missing version following
>> the operator would result in curious errors.
>>
>> The major problem with spaces I see is that it means we end up having
>> an additional [use] block floating following them.
>>
>
> I was also thinking that the logical operators could be infix, and then
> you need the commas to avoid precedence issues with the implicit-and,
> which is written " ".

Commas and spaces can be made optional if we allow the following
tokens to be the delimiter itself.  Grouping and use of white space
can be optionally used in cases where operators would collide, most
especially after :=.

A valid package name entry also signals end of the rules for the previous entry.

Also, precedence issues and confusions can be avoid by relying on more
explicit grouping like () and {}, instead of &&, ||, & and |.

> The [use] blocks could be moved next to the
> package name I guess.

It can actually be allowed to be placed anywhere if we don't use []
for condition grouping, and just use it for the use block.

-- 
konsolebox

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]

On Tue, 8 Nov 2016 19:30:28 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 11/08/2016 10:47 AM, Michał Górny wrote:
> > 
> > Strictly speaking, we don't have to since the lexing should be
> > predictable enough. Of course, mistakes like missing version following
> > the operator would result in curious errors.
> > 
> > The major problem with spaces I see is that it means we end up having
> > an additional [use] block floating following them.
> >   
> 
> I was also thinking that the logical operators could be infix, and then
> you need the commas to avoid precedence issues with the implicit-and,
> which is written " ". The [use] blocks could be moved next to the
> package name I guess. If we were to rewrite the dependency syntax from
> scratch, what would it look like? My first attempt would look something
> like,
> 
>   DEPEND="dev-lang/perl,
>           net-misc/wget || net-misc/curl,

I don't think this is really more readable than || ( ... ). And in most
cases, it would be longer to write too.

>           apache2? ( www-servers/apache[apache2_modules_cgi] >= 2.4 ),

In what order is that interpreted? Remember that you aren't allowed to
reference USE flags not in IUSE without (+) and (-). So if things are
parsed left-to-right, you may end up applying an invalid USE
restriction before the version restriction.

>           ssl? (
> 		!libressl? ( dev-libs/openssl:=0 ),
> 		libressl? ( dev-libs/libressl:= )
> 	  )"
> 
> The reason I'm entertaining this is because the more operators we add,
> the more awkward the prefix notation gets. If we had spaces around the
> operators, they wouldn't need to consist of invalid package characters,
> and we could do something like,
> 
>   DEPEND="app-foo/bar in [1,2]"
> 
> to request a version in the closed interval [1,2]. For (half) exclusive
> ranges, we could have (1,2), (1,2], and [1,2) -- there's no need to
> reinvent that particular wheel. We know that "in" surrounded by spaces
> is an operator, and we know the types of its two arguments. With prefix
> notation, you'd have
> 
>   DEPEND="inapp-foo/bar[1,2]" #fail

It's not prefix notation. Prefix would be:

  in[1,2]app-foo/bar

> There's always ∈, but you still have to figure out what's in the brackets.
> 
> It's fun to brainstorm, but there are probably numerous problems with
> every syntax I've imagined, and the only way to have a meaningful
> discussion about one of them would be to create a reference
> implementation and migrate some ebuilds. Retraining hundreds of
> developers and users is a high bar to set without being damn sure that
> we've got it right.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Michael Orlitzky]

On 11/09/2016 02:42 AM, Michał Górny wrote:
> 
>>           apache2? ( www-servers/apache[apache2_modules_cgi] >= 2.4 ),
> 
> In what order is that interpreted? Remember that you aren't allowed to
> reference USE flags not in IUSE without (+) and (-). So if things are
> parsed left-to-right, you may end up applying an invalid USE
> restriction before the version restriction.
> 

Equivalent to >=www-servers/apache-2.4[apache2_modules_cgi]. The wording
of the PMS might need to be changed, but it makes no difference if you
think of the USE constraint as being applied before or after the version
constraint. In other words, we could make the rule: you can't reference
versions that don't meet a USE constraint without (+) or (-).

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

[konsolebox]

On Tue, Nov 8, 2016 at 11:47 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 8 Nov 2016 10:39:09 -0500
> Michael Orlitzky <mjo@gentoo.org> wrote:
>
>> On 11/08/2016 09:49 AM, Ulrich Mueller wrote:
>> >
>> > This wouldn't completely solve it, because we also have a := slot
>> > operator.
>>
>> Oh, duh...
>>
>>
>> > Brackets would help, or some new separator. Pick your poison:
>>
>> I would really like to have spaces around the infix operators, but then
>> we need to separate the dependencies with a delimiter (like a comma).
>
> Strictly speaking, we don't have to since the lexing should be
> predictable enough. Of course, mistakes like missing version following
> the operator would result in curious errors.
>
> The major problem with spaces I see is that it means we end up having
> an additional [use] block floating following them.

Actually after reading replies from others, I got the idea spaces can
just be made optional, if we use () and {} over & and | (and also have
&& the default function).  Any operator can be a delimiter for itself
or the previous rule:

'dev-foo/bar>=1.3<1.5' is just synonymous to 'dev-foo/bar >= 1.3 <
1.5' or 'dev-foo/bar(>=1.3 <1.5)'.  The beauty there is that it's now
starting to synchronize with the grouping syntax of DEPEND and
RDEPEND.  We would only need to add a space or use grouping if it's
necessary like after using the := operator.

[use] blocks can also be placed anywhere if we only use [] for it, and
use () and {} for grouping versions/slot/repo rules.  And if it would
help, the interpreter can now choose to just interpret/store [use]
block as another condition element with a different class (e.g. use
class) for the sake of simplicity, and restrict it to be only used
once and outside any form of grouping.

There's simplicity in there because you know [] defines flags, while
other operators define version rules.

Btw, & and | can be misused together: dev-foo/bar(condtion & condtion
| condition) and it becomes unclear what comes first before another.
The current DEPEND and RDEPEND syntax avoids it by having && and ||
placed outside of the block.  And if you look at it, () is just
synonymous to '&& ( ... )', and {} is just synonymous to '|| ( ... )'.

-- 
konsolebox

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 3544 bytes --]

>>>>> On Sun, 6 Nov 2016, Michał Górny wrote:

> 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

Thank you for collecting these ideas. As I see it, they can be divided
into two main categories: a) additional functionality and b) syntax
changes. IMHO we shouldn't go for any major syntax change in b),
unless this would be required by an important feature in a).

About the items on the wiki page:

> 1 Reordering to PACKAGE OP VERSION

This is a purely syntactical change. We should not do this without
good reason, i.e. additional functionality that cannot be expressed
with existing syntax.

> 2 Version ranges

I think this is a feature which is needed. However, I am not so sure
if a radical change of syntax would be necessary for it.

The most pressing problem seems to be that the current syntax cannot
specify a version range that must be within the same slot.
Introduction of a slot binding all-of group would solve this.

Looks like all the rest listed under the "version ranges" heading can
already be expressed with existing syntax, although in a verbose way.
So the question is if version ranges occur often enough to justify
introduction of a new and less verbose syntax?

> 3 Version suffixes and upper/lower bound problem

IMHO not worth the effort. Dependencies of "<" type don't occur very
often. Also I would expect that in most cases it will be known what
the next version is. And if not, the relation can still be expressed
with existing syntax (e.g. by appending an _alpha suffix).

> 4 Revision-related operators

Indeed we have some inconsistency there: We have ~ which is like =
but ignoring the revision, but we don't have corresponding operators
for the other four relations. The two ones corresponding to >= and <
would be redundant, though (because the normal >= and < operators
can be used with r0). This leaves us with > (ignoring revision)
and <= (ignoring revision).

Again, not sure how often this would be needed. Adding -r9999 is a
workaround for most (all?) cases occurring in practice.

Besides, what is special about revisions? A revbump potentially comes
with changes (like a security fix) as important as any upstream bump.
I can understand the need for the ~ operator, e.g., to keep packages
in sync that are built from the same upstream tarball. For inequality
relations I have doubts if we need anything revision specific.

> 5 Component-wide prefix comparison

I'd rather not introduce more creative ways how the * wildcard can be
abused. Maybe it could be dropped entirely, assuming we would have
version ranges.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2630 bytes --]

On 11/06/2016 02:52 AM, Michał Górny 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
> 
I think it complicates version matching. Of course, matching the correct
version is a difficult task in itself. Anything that requires the least
necessary change and improves readability and utility the most should
get in. I like the idea of version ranges and slot ranges, but it's
tough to figure out which form is best for that.

Then we have the pesky * that, when used in a version spec, doesn't
follow intuition. Unless a package is slotted for each major or
major.minor version, there isn't a way currently (that I know of) to
express "pull in any version 1.2.x of app-misc/foobar" in a single
declaration/line.

In an attempt at a solution: we already use [] for USE, and () are for
groupings. If bash doesn't yell at us much, maybe {} would be good for
version restrictions. Maybe something like:

>=app-misc/foobar-{1.2..1.4}:=[baz]

To mean "any version of 1.2 or greater, up to version 1.4, inclusive".
We could add in asterisk support to match any sub versions, e.g.
{1.2*..1.4}, but it could get really messy.

While the initial proposal to put the operator in a better place seems
nice on paper, I can only think of the massive amount of work that'd
need to be done to get that change pushed through and re-educate fellow
devs on how to do things going forward. Maybe we should go through some
particularly tricky ebuilds and "try out" the new ideas, to see what the
final product looks like.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]