Dynamic and lazy import

Diez B. Roggisch deets at nospam.web.de
Wed Oct 17 09:56:48 EDT 2007


Alexandre Badez wrote:

> Thanks for all your advices, but it's not really what I would like to
> do.
> 
> I'm going to be more clearer for what I really want to do.
> 
> Here we have got many library for different applications. All those
> library have a version and between a version and an other, there isn't
> always a very good backward compatibility (I know, it's very ugly, but
> it's like that...).
> 
> Moreover some library use the version 1.1 and some the version 1.2 of
> lib A and version 2.1 and version 2.0 of lib B ... you know what: it's
> very ugly.
> 
> My idea was to be able to use lib quiet like that.
> 
> import A (<- If I want to use the very last version)
> # or
> import A.1_1 (<- If I want to use the version 1.1 of the A lib)
> 
> Something else ?
> Yes :)
> I do not want to add all those path in PYTHONPATH (would be too ugly,
> and "complicated").
> I want it lazy (do not import every version of every lib every time)
> I want it scalable: if a user or the admin add a new lib or a version
> of lib it would be very very great if he had nothing else (than copy
> his directory) to do.
> 
> So what I wanted to do, was to be able to control what the user really
> wanted to import, and act he excepted and put the "intelligence" in a
> __init__ script

Use setuptools + pkg_resources to install sereval versions of your libraries
together and then you can require a certain version of your lib.

HOWEVER: this WON'T work for several versions of a library in ONE running
python process!!!! Because the import will then either fail silently (after
all, "import foo" is ignored if foo is already present) or pkg_resources is
so clever that it keeps tracks of requirements and if they are conflicting
will puke on you.

Diez



More information about the Python-list mailing list