2014-02-05 09:08 Mike Frysinger napisał(a):
> 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 ?

E.g. euse, gentoo-bashcomp and potentially other tools written in bash, which need
some data from configuration of repositories.

I would like to provide 3 functions:
- repos_read_config()
  This function would use portageq to set PORTAGE_REPOSITORIES in environment.

  repos_read_config() {
    eval "$(portageq envvar -v PORTAGE_REPOSITORIES)"
  }

  If external consumer needs also other variables, then it can directly use:
  eval "$(portageq envvar -v PORTAGE_REPOSITORIES VAR1 VAR2 VAR3)"

- repos_list()
  This function would print list of names of repositories.

- repo_attr()
  This function would print value of specified attribute (${2}) for specified repository (${1}).
  This function would call __repo_attr() function currently defined in bin/isolated-functions.sh.

Example code:
  . portage.bash
  repos_read_config
  for repo in $(repos_list); do
    location=$(repo_attr ${repo} location)
    …
  done

Calling portageq multiple times would be too slow for some tools.

gentoo-bashcomp contains a custom implementation of parser of repos.conf, which could be replaced by
calls to functions provided by Portage:
http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bashcomp.git;a=commitdiff;h=bf91db09a102544196b21cd792ac423262656a9a

> 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.

${EPREFIX}/usr/bin/portage.bash could be installed without +x permission.

${EPREFIX}/usr/bin is probably in ${PATH} in prefix environment, so ${EPREFIX}/usr/bin/portage.bash
might be easier to use than e.g. ${EPREFIX}/usr/lib/portage.bash.

> 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.

It would result in calling portageq twice instead of once.

--
Arfrever Frehtes Taifersar Arahesis