1 |
On Tue, Nov 8, 2016 at 3:09 PM, konsolebox <konsolebox@×××××.com> wrote: |
2 |
> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@g.o> wrote: |
3 |
>> Hi, everyone. |
4 |
>> |
5 |
>> Following my previous RFC wrt version operator problems, I'd like to |
6 |
>> start the second part of the discussion: how to improve version |
7 |
>> operators in a Future EAPI? |
8 |
>> |
9 |
>> I've collected various ideas on operator changes on a wiki page [1]. |
10 |
>> I've tried to stay open-minded and cover every possibility, even though |
11 |
>> I doubt some of them would be even considered. |
12 |
>> |
13 |
>> I should warn you that some of the solutions are interlinked to each |
14 |
>> other, and you probably need to look through the whole page first |
15 |
>> before starting to construct an opinion. For example, specific |
16 |
>> solutions to most of the problems depend on whether we enable version |
17 |
>> ranges and in which form. |
18 |
>> |
19 |
>> I think we should start by loosely discussing the various ideas |
20 |
>> on the wiki page. Feel free to also point out any missing ideas |
21 |
>> or remarks that would be useful there. |
22 |
>> |
23 |
>> So, what are your comments? |
24 |
>> |
25 |
>> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes |
26 |
>> |
27 |
>> -- |
28 |
>> Best regards, |
29 |
>> Michał Górny |
30 |
>> <http://dev.gentoo.org/~mgorny/> |
31 |
> |
32 |
> I also like the idea of moving the operator as it's more consistent |
33 |
> and opens new doors to other solutions. |
34 |
> |
35 |
> As for the use of operator & and |, they're quite good, but I'd prefer |
36 |
> the use of Gmail's style where expressions placed in () are processed |
37 |
> with AND, and expressions placed inside {} are processed with OR: |
38 |
> |
39 |
> dev-foo/bar[>=1.3&<1.5] dev-foo/bar(>=1.3 <1.5) |
40 |
> dev-foo/bar[>=1.3&<1.5&!=1.4.1] dev-foo/bar(>=1.3 <1.5 !=1.4.1) |
41 |
> dev-foo/bar[<1.1|>=1.5] dev-foo/bar{<1.1 >=1.5} |
42 |
> dev-foo/bar[=1.1*|=1.3*|>=1.5] dev-foo/bar{=1.1* =1.3* >=1.5} |
43 |
> |
44 |
> I find it more readable. The former looks too compressed. |
45 |
|
46 |
I should also add that we can allow slots and repositories in the expressions: |
47 |
|
48 |
dev-foo/bar{:1.3 :1.4 :1.5} ## Solves "A. Range dependencies vs slotting" |
49 |
dev-foo/bar(:1.6 {::local ::devel}) ## Especially useful in |
50 |
/etc/portage/package.{keywords,mask} |
51 |
|
52 |
Along with it, we should also drop the strict order of the slot, |
53 |
version, and repo expressions (just change it to "recommended"). It |
54 |
makes things more flexible and makes it easier for the parser to be |
55 |
implemented. |
56 |
|
57 |
Arithmetic ranges on the other hand should only be in the form of |
58 |
being "inclusive" in both ends, and not exclusive in any. Not only is |
59 |
it simpler; it is also easier to parse. There's also no need to use |
60 |
special grouping operators like {}. E.g. 1.3..1.5. Grouping is only |
61 |
necessary if the form would cause other possible conflicts, where in |
62 |
that case (1.3..1.5) and {1.3..1.5} should just be the same, unless |
63 |
there would be more added expressions in the group. |
64 |
|
65 |
-- |
66 |
konsolebox |