1 |
Dnia 8 listopada 2016 09:17:11 CET, konsolebox <konsolebox@×××××.com> napisał(a): |
2 |
>On Tue, Nov 8, 2016 at 3:09 PM, konsolebox <konsolebox@×××××.com> |
3 |
>wrote: |
4 |
>> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@g.o> |
5 |
>wrote: |
6 |
>>> Hi, everyone. |
7 |
>>> |
8 |
>>> Following my previous RFC wrt version operator problems, I'd like to |
9 |
>>> start the second part of the discussion: how to improve version |
10 |
>>> operators in a Future EAPI? |
11 |
>>> |
12 |
>>> I've collected various ideas on operator changes on a wiki page [1]. |
13 |
>>> I've tried to stay open-minded and cover every possibility, even |
14 |
>though |
15 |
>>> I doubt some of them would be even considered. |
16 |
>>> |
17 |
>>> I should warn you that some of the solutions are interlinked to each |
18 |
>>> other, and you probably need to look through the whole page first |
19 |
>>> before starting to construct an opinion. For example, specific |
20 |
>>> solutions to most of the problems depend on whether we enable |
21 |
>version |
22 |
>>> ranges and in which form. |
23 |
>>> |
24 |
>>> I think we should start by loosely discussing the various ideas |
25 |
>>> on the wiki page. Feel free to also point out any missing ideas |
26 |
>>> or remarks that would be useful there. |
27 |
>>> |
28 |
>>> So, what are your comments? |
29 |
>>> |
30 |
>>> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes |
31 |
>>> |
32 |
>>> -- |
33 |
>>> Best regards, |
34 |
>>> Michał Górny |
35 |
>>> <http://dev.gentoo.org/~mgorny/> |
36 |
>> |
37 |
>> I also like the idea of moving the operator as it's more consistent |
38 |
>> and opens new doors to other solutions. |
39 |
>> |
40 |
>> As for the use of operator & and |, they're quite good, but I'd |
41 |
>prefer |
42 |
>> the use of Gmail's style where expressions placed in () are processed |
43 |
>> with AND, and expressions placed inside {} are processed with OR: |
44 |
>> |
45 |
>> dev-foo/bar[>=1.3&<1.5] dev-foo/bar(>=1.3 <1.5) |
46 |
>> dev-foo/bar[>=1.3&<1.5&!=1.4.1] dev-foo/bar(>=1.3 <1.5 |
47 |
>!=1.4.1) |
48 |
>> dev-foo/bar[<1.1|>=1.5] dev-foo/bar{<1.1 >=1.5} |
49 |
>> dev-foo/bar[=1.1*|=1.3*|>=1.5] dev-foo/bar{=1.1* =1.3* >=1.5} |
50 |
>> |
51 |
>> I find it more readable. The former looks too compressed. |
52 |
> |
53 |
>I should also add that we can allow slots and repositories in the |
54 |
>expressions: |
55 |
> |
56 |
>dev-foo/bar{:1.3 :1.4 :1.5} ## Solves "A. Range dependencies vs |
57 |
>slotting" |
58 |
|
59 |
I'm not sure about this. Slots are kinda special, especially with regard to slot operators. Problems I see: |
60 |
|
61 |
1. := binds to slot of newest version matching the spec. How does this work with your spec? |
62 |
|
63 |
2. Should we allow using := on some of the listed slots? What would happen? |
64 |
|
65 |
3. It's asymmetric since we can't use an AND variant. |
66 |
|
67 |
4. Do we allow different ranges per slots? How do we combine various order of data? |
68 |
|
69 |
>dev-foo/bar(:1.6 {::local ::devel}) ## Especially useful in |
70 |
>/etc/portage/package.{keywords,mask} |
71 |
|
72 |
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. |
73 |
|
74 |
> |
75 |
>Along with it, we should also drop the strict order of the slot, |
76 |
>version, and repo expressions (just change it to "recommended"). It |
77 |
>makes things more flexible and makes it easier for the parser to be |
78 |
>implemented. |
79 |
|
80 |
Problems: |
81 |
|
82 |
1. This could result in fairly ambiguous variants with some syntaxes purposes. |
83 |
|
84 |
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. |
85 |
|
86 |
3. Do we allow multiple occurrences of the same type of element? I'm specifically thinking of multiple disjoint USE dependency blocks. |
87 |
|
88 |
> |
89 |
>Arithmetic ranges on the other hand should only be in the form of |
90 |
>being "inclusive" in both ends, and not exclusive in any. Not only is |
91 |
>it simpler; it is also easier to parse. There's also no need to use |
92 |
>special grouping operators like {}. E.g. 1.3..1.5. Grouping is only |
93 |
>necessary if the form would cause other possible conflicts, where in |
94 |
>that case (1.3..1.5) and {1.3..1.5} should just be the same, unless |
95 |
>there would be more added expressions in the group. |
96 |
|
97 |
I'd say that arithmetic ranges are redundant if we do version ranges. |
98 |
|
99 |
|
100 |
-- |
101 |
Best regards, |
102 |
Michał Górny (by phone) |