From: "Jesus Rivero (Neurogeek)" <neurogeek@gentoo.org>
To: Mike Gilbert <floppym@gentoo.org>
Cc: gentoo-python@lists.gentoo.org, "Michał Górny" <mgorny@gentoo.org>
Subject: Re: [gentoo-python] [python-r1] Getter functions or 'export' function?
Date: Fri, 26 Oct 2012 22:10:46 -0400 [thread overview]
Message-ID: <CAD3zpDk+NFccRBrB8fwio0ZwV-L7YKSQk2x0PJ78hspnRTKB0A@mail.gmail.com> (raw)
In-Reply-To: <CAJ0EP400Fbx7AGjSLXLgOgi7TZq8XAD31yXTE6RvAZc6U2u=pQ@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2012-10-27 2:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-21 9:16 [gentoo-python] [python-r1] Getter functions or 'export' function? Michał Górny
2012-10-22 18:10 ` Mike Gilbert
2012-10-27 1:58 ` Ben de Groot
2012-10-27 2:10 ` Jesus Rivero (Neurogeek) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD3zpDk+NFccRBrB8fwio0ZwV-L7YKSQk2x0PJ78hspnRTKB0A@mail.gmail.com \
--to=neurogeek@gentoo.org \
--cc=floppym@gentoo.org \
--cc=gentoo-python@lists.gentoo.org \
--cc=mgorny@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox