On 03/11/2012 06:55 PM, Brian Harring wrote: > On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote: >> Yeah. Another way of putting it is that the requirement to spawn a bash >> process and source the ebuild adds a ridiculous amount of unnecessary >> complexity, in violation of the KISS principle [1]. > > This statement is incorrect. > > Even if EAPI could be parsed via some non sourcing approach, we > *still* have to source the ebuild to get the metadata for when the > EAPI is supported (the vast majority of usage). That complexity is > there one way or another- we wouldn't be trying to extract the EAPI > from the ebuild unless the cache was invalid/missing.
There are a couple of other cases worth considering: 1) User downloads an overlay that doesn't provide cache. We want the package manager to give a pretty "EAPI unsupported" message, rather than spit out some bash syntax errors. 2) You're assuming that a package manager can validate cache for an EAPI that it doesn't necessarily support. That's a somewhat fragile assumption, given the complexities of cache validation, which involve verification all files that affect metadata and those files may vary depending on the EAPI. > Phrasing it more bluntly: you can only avoid the sourcing step if you > can isolate that the EAPI is unsupported (which is extremely rare in > terms of actual user experience). For the rest of the time (well past > the 99% mark) sourcing is the immediate step following. For the sake of being robust in all possible cases, it's just a lot simpler if we can obtain the EAPI simply and reliably, without spawning bash to source the ebuild. > Also, stop referencing wikipedia. People know what "trivial > objection" and "KISS" is. You can't assume that. On this list we've got potential to have readers and responders with lots of different backgrounds. Your insistence on using bash to obtain the EAPI would make me wonder if you understood the KISS principle, if I didn't know you better. -- Thanks, Zac
