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