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
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 ma
On Wed, Nov 9, 2016 at 7:12 PM, Michał Górny wrote:
>> On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny wrote:
>> >> dev-foo/bar(:* :=) renders :* meaningless since := restricts any
>> >> installed runtime dependency's slot and subslot to be currently
>> >> available. It's still algorithmically corr
On Wed, 9 Nov 2016 18:17:25 +0800
konsolebox wrote:
> On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny wrote:
> > On Wed, 9 Nov 2016 14:32:33 +0800
> > konsolebox 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
On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny wrote:
> On Wed, 9 Nov 2016 14:32:33 +0800
> konsolebox wrote:
>
>> On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny wrote:
>> >>dev-foo/bar{:1.3 :1.4 :1.5} ## Solves "A. Range dependencies vs
>> >>slotting"
>> >
>> > I'm not sure about this. Slots are k
On Tue, 8 Nov 2016 19:30:28 -0500
Michael Orlitzky 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 error
On Wed, 9 Nov 2016 14:32:33 +0800
konsolebox wrote:
> On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny 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.
On Wed, Nov 9, 2016 at 8:30 AM, Michael Orlitzky 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.
>>
>>
On Tue, Nov 8, 2016 at 11:47 PM, Michał Górny wrote:
> On Tue, 8 Nov 2016 10:39:09 -0500
> Michael Orlitzky 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 wou
On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny wrote:
> Dnia 8 listopada 2016 09:17:11 CET, konsolebox
> napisał(a):
>>On Tue, Nov 8, 2016 at 3:09 PM, konsolebox
>>wrote:
>>> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny
>>wrote:
Hi, everyone.
Following my previous RFC wrt version
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
On Tue, 8 Nov 2016 10:39:09 -0500
Michael Orlitzky 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 wou
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
> 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 ch
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 throu
On Tue, Nov 8, 2016 at 6:28 PM, Michał Górny wrote:
> Dnia 8 listopada 2016 08:09:55 CET, konsolebox
> napisał(a):
>>On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny wrote:
>>> Hi, everyone.
>>>
>>> Following my previous RFC wrt version operator problems, I'd like to
>>> start the second part of th
Dnia 8 listopada 2016 09:17:11 CET, konsolebox
napisał(a):
>On Tue, Nov 8, 2016 at 3:09 PM, konsolebox
>wrote:
>> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny
>wrote:
>>> Hi, everyone.
>>>
>>> Following my previous RFC wrt version operator problems, I'd like to
>>> start the second part of the
Dnia 8 listopada 2016 08:09:55 CET, konsolebox
napisał(a):
>On Sun, Nov 6, 2016 at 6:52 PM, 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
On Tue, Nov 8, 2016 at 3:09 PM, konsolebox wrote:
> On Sun, Nov 6, 2016 at 6:52 PM, 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?
>>
On 08/11/16 08:03, konsolebox wrote:
> On Tue, Nov 8, 2016 at 3:49 PM, M. J. Everitt 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
On Tue, Nov 8, 2016 at 3:49 PM, M. J. Everitt wrote:
> On 08/11/16 07:09, konsolebox wrote:
>> On Sun, Nov 6, 2016 at 6:52 PM, 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 imp
On 08/11/16 07:09, konsolebox wrote:
> On Sun, Nov 6, 2016 at 6:52 PM, 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 collec
On Sun, Nov 6, 2016 at 6:52 PM, 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 wik
On Mon, 7 Nov 2016 22:47:24 +0200
Alon Bar-Lev 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 you
> 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 trans
On Mon, 7 Nov 2016 22:47:24 +0200
Alon Bar-Lev wrote:
> On 6 November 2016 at 12:52, Michał Górny wrote:
> > Hi, everyone.
>
>
>
> > 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.
On Mon, 7 Nov 2016 22:47:24 +0200
Alon Bar-Lev wrote:
> On 6 November 2016 at 12:52, Michał Górny wrote:
> > Hi, everyone.
>
>
>
> > 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.
On 6 November 2016 at 12:52, Michał Górny wrote:
> Hi, everyone.
> 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 abnormalit
On Sun, 6 Nov 2016 18:05:39 +0100
"Jan Chren (rindeal)" 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 '
First of all thank you for the research and wish you a good luck in
making the changes happen.
## Reordering to PACKAGE OP VERSION
[ ] [:]
is more sane than
[:] [ ]
even though it's not so "hierarchically correct".
Thus instead of writing
dev-foo/bar:4===4.1
one would write
dev-foo/bar=
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 possib
31 matches
Mail list logo
