[gentoo-python] [python-r1] Getter functions or 'export' function?

[gentoo-python] [python-r1] Getter functions or 'export' function?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

Hello,

Right now, there are two variables which are set per-implementation --
PYTHON & EPYTHON. However, one of our users (sorry for not remembering
who) requested an ability to get Python libdir, site-packages directory
as well. This raises a question on the interface which should be used
to get those values.

The common interface in Gentoo is to use 'getter' functions. Since bash
doesn't have any real concept of return values, those functions use
output capturing -- and that involves subshelling which is pretty bad
for commonly used functions. An alternative is to use an 'export'
function like tc-export() in toolchain-funcs.

I'd like to shortly point out advantages and disadvantages of each
solution.


1) getter functions
   - python_get_PYTHON [<impl>]
   - python_get_EPYTHON <impl>
   - python_get_sitedir [<impl>]

+ clear separation between variables
  -> especially useful to keep docs clear and short

- one subshell (and function call) for each variable, for each
  implementation
  -> that makes it 2 * n-impls for each phase function in distutils-r1


2) a single export function
   - python_export [<impl>] <var>...
   e.g. python_export python2_7 PYTHON EPYTHON PYTHON_SITEDIR

+ no subshelling

+ multiple variables can be set in a single function call

- potential for variable conflicts
  -> e.g. when PYTHON_SITEDIR is used differently by the build system,
     the ebuild would need to 'move' it (unlikely but possible)

- mixing of implementation and variables in parameters (optional first
  parameter)
  -> technically it's acceptable but looks a bit bad.


What are your thoughts?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-python] [python-r1] Getter functions or 'export' function?

[Mike Gilbert]

On Sun, Oct 21, 2012 at 5:16 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Hello,
>
> Right now, there are two variables which are set per-implementation --
> PYTHON & EPYTHON. However, one of our users (sorry for not remembering
> who) requested an ability to get Python libdir, site-packages directory
> as well. This raises a question on the interface which should be used
> to get those values.
>
> The common interface in Gentoo is to use 'getter' functions. Since bash
> doesn't have any real concept of return values, those functions use
> output capturing -- and that involves subshelling which is pretty bad
> for commonly used functions. An alternative is to use an 'export'
> function like tc-export() in toolchain-funcs.
>
> I'd like to shortly point out advantages and disadvantages of each
> solution.
>
>
> 1) getter functions
>    - python_get_PYTHON [<impl>]
>    - python_get_EPYTHON <impl>
>    - python_get_sitedir [<impl>]
>
> + clear separation between variables
>   -> especially useful to keep docs clear and short
>
> - one subshell (and function call) for each variable, for each
>   implementation
>   -> that makes it 2 * n-impls for each phase function in distutils-r1
>
>
> 2) a single export function
>    - python_export [<impl>] <var>...
>    e.g. python_export python2_7 PYTHON EPYTHON PYTHON_SITEDIR
>
> + no subshelling
>
> + multiple variables can be set in a single function call
>
> - potential for variable conflicts
>   -> e.g. when PYTHON_SITEDIR is used differently by the build system,
>      the ebuild would need to 'move' it (unlikely but possible)
>
> - mixing of implementation and variables in parameters (optional first
>   parameter)
>   -> technically it's acceptable but looks a bit bad.
>
>
> What are your thoughts?
>

I think creating sub-shells in sections which are not processed in
global scope is really not a big deal.

I think the getter functions are more intuitive. However, I also like
the idea of setting variables at the same time, similar to the way
this is handled in _tc-getPROG. The result is stored in a variable and
also echoed, leaving it up to the end user to decide how he wants to
process it.

So, I vote for getters that emulate the toolchain-funcs behavior.

Re: [gentoo-python] [python-r1] Getter functions or 'export' function?

[Ben de Groot]

On 23 October 2012 02:10, Mike Gilbert <floppym@gentoo.org> wrote:
> On Sun, Oct 21, 2012 at 5:16 AM, Michał Górny <mgorny@gentoo.org> wrote:
>> What are your thoughts?
>>
>
> I think creating sub-shells in sections which are not processed in
> global scope is really not a big deal.
>
> I think the getter functions are more intuitive. However, I also like
> the idea of setting variables at the same time, similar to the way
> this is handled in _tc-getPROG. The result is stored in a variable and
> also echoed, leaving it up to the end user to decide how he wants to
> process it.
>
> So, I vote for getters that emulate the toolchain-funcs behavior.
>

+1

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-python] [python-r1] Getter functions or 'export' function?

[Jesus Rivero (Neurogeek)]

[-- Attachment #1: Type: text/plain, Size: 2568 bytes --]

On Oct 22, 2012 2:10 PM, "Mike Gilbert" <floppym@gentoo.org> wrote:
>
> On Sun, Oct 21, 2012 at 5:16 AM, Michał Górny <mgorny@gentoo.org> wrote:
> > Hello,
> >
> > Right now, there are two variables which are set per-implementation --
> > PYTHON & EPYTHON. However, one of our users (sorry for not remembering
> > who) requested an ability to get Python libdir, site-packages directory
> > as well. This raises a question on the interface which should be used
> > to get those values.
> >
> > The common interface in Gentoo is to use 'getter' functions. Since bash
> > doesn't have any real concept of return values, those functions use
> > output capturing -- and that involves subshelling which is pretty bad
> > for commonly used functions. An alternative is to use an 'export'
> > function like tc-export() in toolchain-funcs.
> >
> > I'd like to shortly point out advantages and disadvantages of each
> > solution.
> >
> >
> > 1) getter functions
> >    - python_get_PYTHON [<impl>]
> >    - python_get_EPYTHON <impl>
> >    - python_get_sitedir [<impl>]
> >
> > + clear separation between variables
> >   -> especially useful to keep docs clear and short
> >
> > - one subshell (and function call) for each variable, for each
> >   implementation
> >   -> that makes it 2 * n-impls for each phase function in distutils-r1
> >
> >
> > 2) a single export function
> >    - python_export [<impl>] <var>...
> >    e.g. python_export python2_7 PYTHON EPYTHON PYTHON_SITEDIR
> >
> > + no subshelling
> >
> > + multiple variables can be set in a single function call
> >
> > - potential for variable conflicts
> >   -> e.g. when PYTHON_SITEDIR is used differently by the build system,
> >      the ebuild would need to 'move' it (unlikely but possible)
> >
> > - mixing of implementation and variables in parameters (optional first
> >   parameter)
> >   -> technically it's acceptable but looks a bit bad.
> >
> >
> > What are your thoughts?
> >
>
> I think creating sub-shells in sections which are not processed in
> global scope is really not a big deal.
>
> I think the getter functions are more intuitive. However, I also like
> the idea of setting variables at the same time, similar to the way
> this is handled in _tc-getPROG. The result is stored in a variable and
> also echoed, leaving it up to the end user to decide how he wants to
> process it.
>
> So, I vote for getters that emulate the toolchain-funcs behavior.
>
+1 from me too. But lets avoid redundancy in variable names, please.

[-- Attachment #2: Type: text/html, Size: 3391 bytes --]