All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Lock <josh@openedhand.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: poky@yoctoproject.org
Subject: Re: [PATCH 3/7] bb: add bb.fetcher as dynamic fetch module instance for fetch/fetch2
Date: Tue, 11 Jan 2011 11:54:49 +0000	[thread overview]
Message-ID: <1294746889.2516.0.camel@scimitar> (raw)
In-Reply-To: <1294690775.1492.1258.camel@rex>

On Mon, 2011-01-10 at 20:19 +0000, Richard Purdie wrote:
> On Mon, 2011-01-10 at 16:43 +0000, Richard Purdie wrote:
> > On Mon, 2011-01-10 at 11:42 +0000, Richard Purdie wrote:
> > > On Mon, 2011-01-10 at 10:13 +0000, Joshua Lock wrote:
> > > > On Sat, 2011-01-08 at 15:15 +0800, Yu Ke wrote:
> > > > > +import bb
> > > > > +from bb import fetch, fetch2
> > > > > +
> > > > > +# switch between fetch and fetch2
> > > > > +instance = bb.fetch
> > > > > +__version__ = "1"
> > > > > +
> > > > > +#instance = bb.fetch2
> > > > > +#__version__ = "2"
> > > > 
> > > > I'm not very happy with this, it doesn't feel right. Can we not add some
> > > > runtime determination of which module to use (a variable in
> > > > bitbake.conf?) and then use some dynamic Python magic to add it to the
> > > > imported modules list?
> > > > 
> > > > A quick Google makes me thing we could do something more dynamic with
> > > > the __import__() function.
> > > 
> > > Agreed, I was also thinking about this but wanted to come up with a
> > > suggestion about how to better handle it. There is some interesting info
> > > in this webpage:
> > > 
> > > http://stackoverflow.com/questions/1096216/override-namespace-in-python
> > > 
> > > This example in particular looks useful:
> > > 
> > > def weirdimport(fullpath):
> > >   global project
> > > 
> > >   import os
> > >   import sys
> > >   sys.path.append(os.path.dirname(fullpath))
> > >   try:
> > >       project = __import__(os.path.basename(fullpath))
> > >       sys.modules['project'] = project
> > >   finally:
> > >       del sys.path[-1]
> > > 
> > > Although we shouldn't need to manipulate sys.path in our case.
> > > 
> > > As Joshua mentions, overriding the __import__ builtin should also work
> > > and might avoid some ordering issues we'd have with the above.
> > 
> > I did come up with this code inserted at the start of bin/bitbake:
> > 
> > origimport = __builtins__.__import__
> > def bbimport(name, *args, **kwargs):
> >     newname = name
> >     if name.find("bb.fetch") != -1:
> >         newname = name.replace("bb.fetch", "bb.fetch2")
> >     ret = origimport(newname, *args, **kwargs)
> >     if name != newname:
> >         sys.modules[name] = sys.modules[newname]
> >         if name == "bb.fetch":
> >             bb.fetch = sys.modules[newname]
> >     return ret
> > if os.environ.get('BBFETCH2'):
> >     __builtins__.__import__ = bbimport
> > 
> > which is pretty ugly :(. The big advantage of this is that it does
> > redirect any bb.fetch calls into bb.fetch2 calls, even within the
> > bb.fetch2 codebase.
> > 
> > I'm working through some other ideas as time permits.
> 
> If we assume bb.fetch2 will not make calls to bb.fetch we can simplify
> this to:
> 
> if os.environ.get("BBFETCH2"):
>     from bb import fetch2 as fetch
>     sys.modules['bb.fetch'] = sys.modules['bb.fetch2']

Lovely, this is almost exactly what I had envisaged :-)

Cheers,
Joshua

> 
> so from the environment you can trigger the new fetcher code. For Poky,
> I've added something to hardcode that behaviour since I don't want it to
> break.
> 
> I've pushed this both into Poky and bitbake upstream so we're in sync
> and can move forward on improving the fetcher code :).
> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> 
> 

-- 
Joshua Lock
        Intel Open Source Technology Centre



  parent reply	other threads:[~2011-01-11 11:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-08  7:14 [PATCH 0/7] add initial bb.fetch2 code Yu Ke
2011-01-08  7:14 ` [PATCH 1/7] fetch2: copy bb.fetch to bb.fetch2 as initial code base Yu Ke
2011-01-08  7:15 ` [PATCH 2/7] bb.fetch2: replace bb.fetch with bb.fetch2 in the bb.fetch2 Yu Ke
2011-01-08  7:15 ` [PATCH 3/7] bb: add bb.fetcher as dynamic fetch module instance for fetch/fetch2 Yu Ke
2011-01-10 10:13   ` Joshua Lock
2011-01-10 11:42     ` Richard Purdie
2011-01-10 16:43       ` Richard Purdie
2011-01-10 20:19         ` Richard Purdie
2011-01-11  0:06           ` Yu Ke
2011-01-11  0:13           ` Yu Ke
2011-01-11  0:50             ` Richard Purdie
2011-01-11  1:16               ` Yu Ke
2011-01-11 11:54           ` Joshua Lock [this message]
2011-01-08  7:15 ` [PATCH 4/7] BBHandler: remove bb.fetch referrence Yu Ke
2011-01-08  7:15 ` [PATCH 5/7] bb.cooker: remove bb.fetch.persistent_database_connection referrence Yu Ke
2011-01-08  7:15 ` [PATCH 6/7] bb: replace bb.fetch referrence with bb.fetcher instance Yu Ke
2011-01-08  7:15 ` [PATCH 7/7] bbclass: replace the " Yu Ke

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=1294746889.2516.0.camel@scimitar \
    --to=josh@openedhand.com \
    --cc=poky@yoctoproject.org \
    --cc=richard.purdie@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.