[poky] [PATCH 3/7] bb: add bb.fetcher as dynamic fetch module instance for fetch/fetch2

[Richard Purdie]

On Mon, 2011-01-10 at 10:13 +0000, Joshua Lock wrote:
> On Sat, 2011-01-08 at 15:15 +0800, Yu Ke wrote:
> > bb.fetcher is introduced to swtich between bb.fetch and bb.fetch2.
> > all bb.fetch/bb.fetch2 referrence can be replaced with bb.fetcher.instance,
> > so that we can cleanly switch between bb.fetch and bb.fetch2
> > 
> > Signed-off-by: Yu Ke <ke.yu at intel.com>
> > ---
> >  bitbake/lib/bb/fetcher.py |   26 ++++++++++++++++++++++++++
> >  1 files changed, 26 insertions(+), 0 deletions(-)
> >  create mode 100644 bitbake/lib/bb/fetcher.py
> > 
> > diff --git a/bitbake/lib/bb/fetcher.py b/bitbake/lib/bb/fetcher.py
> > new file mode 100644
> > index 0000000..3818d78
> > --- /dev/null
> > +++ b/bitbake/lib/bb/fetcher.py
> > @@ -0,0 +1,26 @@
> > +#!/usr/bin/env python
> > +# ex:ts=4:sw=4:sts=4:et
> > +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
> > +#
> > +# This program is free software; you can redistribute it and/or modify
> > +# it under the terms of the GNU General Public License version 2 as
> > +# published by the Free Software Foundation.
> > +#
> > +# This program is distributed in the hope that it will be useful,
> > +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +# GNU General Public License for more details.
> > +#
> > +# You should have received a copy of the GNU General Public License along
> > +# with this program; if not, write to the Free Software Foundation, Inc.,
> > +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > +
> > +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.

Cheers,

Richard