Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
2011/12/29 Brian Harring ferri...@gmail.com: On Thu, Dec 29, 2011 at 02:37:07AM +, Francesco Riosa wrote: 2011/12/28 Zac Medico zmed...@gentoo.org: On 12/28/2011 05:12 AM, Francesco Riosa wrote: Seem to me that append a time slice to the function, in the name or as a parent function that call the underling function can solve most of the versioning/deprecation problems I've overheard Arfrever discussing a similar approach in funtoo's irc channel, where the ebuild would set a variable prior to inherit if it wants to use a specific eclass API. For the python eclass, he's planning to have ebuilds set the PYTHON_ECLASS_API variable to use the new API. When the variable is unset, the eclass will default to the older API. There is a fundamental difference, with timeslices it's not the ebuild that select the implementation but the point in time it's used, or the user forcing a fake time. From what I've read Artfever approach require changes in every ebuild and keeping old functions forever. On the other hand it may be risky to change the preferred interface from the eclass and not the ebuild. Respectfully, the proposals thus far (including python eclass bit) are going in the opposite direction of maintainability, simplicity, robustness. People have problems as is dealing w/ eclasses changing and their dependencies in external repositories not being updated; this complicates that issue and introduces the same potential into gentoo-x86 itself. That's not beneficial. Thing to keep in mind beyond the potential for confusion the proposals entail were they implemented, is the implementation itself. Timeslices? python eclass api versions (when people have problems figuring out the existing, *singular* version)? These things aren't going to be simple which means more than likely, they're going to break, and more than likely it's going to be a PITA to maintain it. Per the norm, I could be wrong, but reading these proposals, they really feel like they need to revisit the notion of maintainability/robustness as an actual full fledged implementation, beyond the (admittedly semi nifty) notion of versioned apis. My 2 cents, hopefully not at my usual offensive level- ~harring yeah, after a good sleep the problems of this approach are more clear, it's a pity, it seemed really bright while eating my spaghetti.
Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
On Wed, 28 Dec 2011 19:36:01 -0800
Brian Harring ferri...@gmail.com wrote:
People have problems as is dealing w/ eclasses changing and their
dependencies in external repositories not being updated; this
complicates that issue and introduces the same potential into
gentoo-x86 itself. That's not beneficial.
I agree with nearly all of that: introducing changes to an eclass
usually means going through the whole tree and fixing what breaks.
That's a lot more easy to fix than adding more layers of indirection
based on a variable's value and adjusting the value according to the
time the ebuild was written versus when the eclass was changed.
Thing to keep in mind beyond the potential for confusion the
proposals entail were they implemented, is the implementation
itself. Timeslices? python eclass api versions (when people have
problems figuring out the existing, *singular* version)? These
things aren't going to be simple which means more than likely,
they're going to break, and more than likely it's going to be a PITA
to maintain it.
Last time I took tranquilisers and set myself up to read python.eclass,
I found that it still doesn't break at 80 characters. Apparently even
that can't be fixed in a timely fashion.
Assing even more layers of mystification like:
if [[ PYTHON_ECLASS_API = 2 ]]; then
python_pkg_setup() {
or even:
python_pkg_setup() {
if [[ PYTHON_ECLASS_API = 2 ]]; then
would be insane, in my opinion.
Also, from the perspective of an ebuild writer, setting
PYTHON_ECLASS_API=2
inherit python
would be meaningless lacking a very clear description of what the
number 2 means.
jer
Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
On 12/28/2011 05:12 AM, Francesco Riosa wrote: Disclaimer: this is just one idea that come at lunch, and sharing (in a short pause before my demanding daughter request me) here to not forget in the next busy days. Seem to me that append a time slice to the function, in the name or as a parent function that call the underling function can solve most of the versioning/deprecation problems how could it work: 1) package manager record the time it start an emerge transaction, and share it via the environment with ebuilds and eclasses. The time could be faked by an argument via command line too. 2) the bash functions which are versioned this way chose the right one 3) package manager save the build time in the binpkg and in /var/db for unmergin and other purposes You're idea is irrelevant for binary packages and unmerge of installed packages, since they make use of environment.bz2 which contains a snapshot of the eclass functions / environment from build time. -- Thanks, Zac
Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
On 12/28/2011 05:12 AM, Francesco Riosa wrote: Seem to me that append a time slice to the function, in the name or as a parent function that call the underling function can solve most of the versioning/deprecation problems I've overheard Arfrever discussing a similar approach in funtoo's irc channel, where the ebuild would set a variable prior to inherit if it wants to use a specific eclass API. For the python eclass, he's planning to have ebuilds set the PYTHON_ECLASS_API variable to use the new API. When the variable is unset, the eclass will default to the older API. -- Thanks, Zac
Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
2011/12/28 Zac Medico zmed...@gentoo.org: On 12/28/2011 05:12 AM, Francesco Riosa wrote: Disclaimer: this is just one idea that come at lunch, and sharing (in a short pause before my demanding daughter request me) here to not forget in the next busy days. Seem to me that append a time slice to the function, in the name or as a parent function that call the underling function can solve most of the versioning/deprecation problems how could it work: 1) package manager record the time it start an emerge transaction, and share it via the environment with ebuilds and eclasses. The time could be faked by an argument via command line too. 2) the bash functions which are versioned this way chose the right one 3) package manager save the build time in the binpkg and in /var/db for unmergin and other purposes You're idea is irrelevant for binary packages and unmerge of installed packages, since they make use of environment.bz2 which contains a snapshot of the eclass functions / environment from build time. The environment would contain all the versioned functions but it will also contain the timestamp of the original merge possibly solving the dilemma
Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
2011/12/28 Zac Medico zmed...@gentoo.org: On 12/28/2011 05:12 AM, Francesco Riosa wrote: Seem to me that append a time slice to the function, in the name or as a parent function that call the underling function can solve most of the versioning/deprecation problems I've overheard Arfrever discussing a similar approach in funtoo's irc channel, where the ebuild would set a variable prior to inherit if it wants to use a specific eclass API. For the python eclass, he's planning to have ebuilds set the PYTHON_ECLASS_API variable to use the new API. When the variable is unset, the eclass will default to the older API. There is a fundamental difference, with timeslices it's not the ebuild that select the implementation but the point in time it's used, or the user forcing a fake time. From what I've read Artfever approach require changes in every ebuild and keeping old functions forever. On the other hand it may be risky to change the preferred interface from the eclass and not the ebuild. Thanks for reviewing, Francesco
Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
On Thu, Dec 29, 2011 at 02:37:07AM +, Francesco Riosa wrote: 2011/12/28 Zac Medico zmed...@gentoo.org: On 12/28/2011 05:12 AM, Francesco Riosa wrote: Seem to me that append a time slice to the function, in the name or as a parent function that call the underling function can solve most of the versioning/deprecation problems I've overheard Arfrever discussing a similar approach in funtoo's irc channel, where the ebuild would set a variable prior to inherit if it wants to use a specific eclass API. For the python eclass, he's planning to have ebuilds set the PYTHON_ECLASS_API variable to use the new API. When the variable is unset, the eclass will default to the older API. There is a fundamental difference, with timeslices it's not the ebuild that select the implementation but the point in time it's used, or the user forcing a fake time. From what I've read Artfever approach require changes in every ebuild and keeping old functions forever. On the other hand it may be risky to change the preferred interface from the eclass and not the ebuild. Respectfully, the proposals thus far (including python eclass bit) are going in the opposite direction of maintainability, simplicity, robustness. People have problems as is dealing w/ eclasses changing and their dependencies in external repositories not being updated; this complicates that issue and introduces the same potential into gentoo-x86 itself. That's not beneficial. Thing to keep in mind beyond the potential for confusion the proposals entail were they implemented, is the implementation itself. Timeslices? python eclass api versions (when people have problems figuring out the existing, *singular* version)? These things aren't going to be simple which means more than likely, they're going to break, and more than likely it's going to be a PITA to maintain it. Per the norm, I could be wrong, but reading these proposals, they really feel like they need to revisit the notion of maintainability/robustness as an actual full fledged implementation, beyond the (admittedly semi nifty) notion of versioned apis. My 2 cents, hopefully not at my usual offensive level- ~harring
