Re: [gentoo-portage-dev] [RFC] Location of Portage bash API (outside of ebuilds)
On Saturday, February 01, 2014 21:08:11 Arfrever Frehtes Taifersar Arahesis wrote: bin/isolated-functions.sh contains at least 1 useful function, which could be exposed for external consumers (without __ prefix), but must have private name (with __ prefix) when bin/isolated-functions.sh is used in ebuild environment. who are these mysterious external consumers ? what you propose means all funcs in there now become exported API and we now have to live with that. w/out any real background, i'm very hesitant to allow that. Possible solutions: 1. Make /usr/lib/portage/bin/isolated-functions.sh magically define non-private variants of useful functions when run in non-ebuild environment. this is a no-go. we should be cutting down on internal overhead. 2. Provide /usr/bin/portage.bash, which would source isolated-functions.sh (and maybe other files) and define non-private variants of useful functions. /usr/bin/portage.bash would be easier sourceable due to PATH. 3. Provide /usr/lib/portage.bash, which would source isolated-functions.sh (and maybe other files) and define non-private variants of useful functions. 4. Another location... (I would probably prefer solution #2.) sounds like a file that should be sourced only which imo bans it from $PATH. i'm aware of the magic shell behavior where `source` searches PATH, but that's not an acceptable reason imo. easy to add something like `portageq helpers-dir` that'd give you a path and then you use that to load the various scripts directly. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [RFC] Location of Portage bash API (outside of ebuilds)
On Sat, Feb 1, 2014 at 12:08 PM, Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: bin/isolated-functions.sh contains at least 1 useful function, which could be exposed for external consumers (without __ prefix), but must have private name (with __ prefix) when bin/isolated-functions.sh is used in ebuild environment. Possible solutions: 1. Make /usr/lib/portage/bin/isolated-functions.sh magically define non-private variants of useful functions when run in non-ebuild environment. 2. Provide /usr/bin/portage.bash, which would source isolated-functions.sh (and maybe other files) and define non-private variants of useful functions. /usr/bin/portage.bash would be easier sourceable due to PATH. 3. Provide /usr/lib/portage.bash, which would source isolated-functions.sh (and maybe other files) and define non-private variants of useful functions. 4. Another location... (I would probably prefer solution #2.) I think 1 isn't very unix-y, 2-3 are fine. If we expect users to run it, it goes in bin, if not, then lib. -A -- Arfrever Frehtes Taifersar Arahesis
