| 1 |
On Saturday, February 01, 2014 21:08:11 Arfrever Frehtes Taifersar Arahesis |
| 2 |
wrote: |
| 3 |
> bin/isolated-functions.sh contains at least 1 useful function, which could |
| 4 |
> be exposed for external consumers (without __ prefix), but must have |
| 5 |
> private name (with __ prefix) when bin/isolated-functions.sh is used in |
| 6 |
> ebuild environment. |
| 7 |
|
| 8 |
who are these mysterious external consumers ? |
| 9 |
|
| 10 |
what you propose means all funcs in there now become exported API and we now |
| 11 |
have to live with that. w/out any real background, i'm very hesitant to allow |
| 12 |
that. |
| 13 |
|
| 14 |
> Possible solutions: |
| 15 |
> 1. Make /usr/lib/portage/bin/isolated-functions.sh magically define |
| 16 |
> non-private variants of useful functions when run in non-ebuild |
| 17 |
> environment. |
| 18 |
|
| 19 |
this is a no-go. we should be cutting down on internal overhead. |
| 20 |
|
| 21 |
> 2. Provide /usr/bin/portage.bash, which would source isolated-functions.sh |
| 22 |
> (and maybe other files) and define non-private variants of useful |
| 23 |
> functions. /usr/bin/portage.bash would be easier sourceable due to PATH. |
| 24 |
> 3. Provide /usr/lib/portage.bash, which would source isolated-functions.sh |
| 25 |
> (and maybe other files) and define non-private variants of useful |
| 26 |
> functions. |
| 27 |
> 4. Another location... |
| 28 |
> |
| 29 |
> (I would probably prefer solution #2.) |
| 30 |
|
| 31 |
sounds like a file that should be sourced only which imo bans it from $PATH. |
| 32 |
i'm aware of the magic shell behavior where `source` searches PATH, but that's |
| 33 |
not an acceptable reason imo. |
| 34 |
|
| 35 |
easy to add something like `portageq helpers-dir` that'd give you a path and |
| 36 |
then you use that to load the various scripts directly. |
| 37 |
-mike |
Archives