1 |
2011/12/29 Brian Harring <ferringb@×××××.com>: |
2 |
> On Thu, Dec 29, 2011 at 02:37:07AM +0000, Francesco Riosa wrote: |
3 |
>> 2011/12/28 Zac Medico <zmedico@g.o>: |
4 |
>> > On 12/28/2011 05:12 AM, Francesco Riosa wrote: |
5 |
>> >> Seem to me that append a time slice to the function, in the name or as |
6 |
>> >> a parent function that call the underling function can solve most of |
7 |
>> >> the versioning/deprecation problems |
8 |
>> > |
9 |
>> > I've overheard Arfrever discussing a similar approach in funtoo's irc |
10 |
>> > channel, where the ebuild would set a variable prior to inherit if it |
11 |
>> > wants to use a specific eclass API. For the python eclass, he's planning |
12 |
>> > to have ebuilds set the PYTHON_ECLASS_API variable to use the new API. |
13 |
>> > When the variable is unset, the eclass will default to the older API. |
14 |
>> |
15 |
>> There is a fundamental difference, with "timeslices" it's not the |
16 |
>> ebuild that select the implementation but the point in time it's used, |
17 |
>> or the user forcing a fake time. From what I've read Artfever approach |
18 |
>> require changes in every ebuild and keeping old functions forever. On |
19 |
>> the other hand it may be risky to change the preferred interface from |
20 |
>> the eclass and not the ebuild. |
21 |
> |
22 |
> Respectfully, the proposals thus far (including python eclass bit) are |
23 |
> going in the opposite direction of maintainability, simplicity, |
24 |
> robustness. |
25 |
> |
26 |
> People have problems as is dealing w/ eclasses changing and their |
27 |
> dependencies in external repositories not being updated; this |
28 |
> complicates that issue and introduces the same potential into |
29 |
> gentoo-x86 itself. That's not beneficial. |
30 |
> |
31 |
> Thing to keep in mind beyond the potential for confusion the proposals |
32 |
> entail were they implemented, is the implementation itself. |
33 |
> Timeslices? python eclass api versions (when people have problems |
34 |
> figuring out the existing, *singular* version)? These things aren't |
35 |
> going to be simple which means more than likely, they're going to |
36 |
> break, and more than likely it's going to be a PITA to maintain it. |
37 |
> |
38 |
> Per the norm, I could be wrong, but reading these proposals, they |
39 |
> really feel like they need to revisit the notion of |
40 |
> maintainability/robustness as an actual full fledged implementation, |
41 |
> beyond the (admittedly semi nifty) notion of versioned apis. |
42 |
> |
43 |
> My 2 cents, hopefully not at my usual offensive level- |
44 |
> ~harring |
45 |
> |
46 |
yeah, after a good sleep the problems of this approach are more clear, |
47 |
it's a pity, it seemed really bright while eating my spaghetti. |