Disregard the first part of my original post. I've looked at your
code and you've done the logical thing. But your original email did
not state it properly.
For the record of those reading:
If you have a module that you want to use in applications/<appname>/
modules, with this new addition you can:
mod_name = local_import('mod_name')
and it will pull it in as "import mod_name" would if applications/
<appname>/modules were added to sys.path.
For Massimo, I still think you should switch the "force" param to
"reload" for clarity reasons.
-tim
On Oct 30, 8:01 am, Timbo <tfarr...@swgen.com> wrote:
> I like the idea and I am very much against ugliness...however:
>
> d = local_import('a.b.c')
>
> is way uglier in my book than:
>
> import a.b.c as d
>
> Asthetics aside, it does not solve the original problem very well.
> The problem is not being able to do:
>
> import c as d
>
> when d is in apps/init/modules because sys.path is global.
>
> A much better solution is to change local_import to be just this:
>
> d = local_import('c')
>
> Because you are in an app the 'a.b' part is assumed.
>
> Also, I like the ", force=True" part, but call it "reload" instead
> since that better describes what it does, otherwise, "what the heck
> are we forcing?" is a valid question.
>
> If you need a patch for this, let me know. I don't mind.
>
> Just my 22222c,
> -tim
>
> On Oct 30, 12:55 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > Something always bothered be and resulted in lots of uglyness. I
> > suspected there was a way to fix it but did not know. Now I found out.
>
> > The problem:
> > ==========
>
> > when we do
>
> > import a.b.c as d
>
> > Python (and web2py) look in sys.path.
> > If the module is in "web2py/applications/yourapp/modules" then
> > "web2py/applications/yourapp/modules" should be added to sys.path.
> > This would cause a major problem if there are many web2py apps that
> > have a file a/b/c.py in modules. The import would find the first one,
> > not necessarily the one in the current app.
> > sys.path is not thread safe. There only a global sys.path not one per
> > thread.
> > So far the suggested solution was not do add the app modules path to
> > sys.path and instead we used to do:
>
> > exec('import applications.%s.modules.a.b.c as d' %
> > request.application) # UGLY!
>
> > This solves the conflict between app of modules but not conflicts with
> > modules that are in sys.path.
> > This limits which modules can go in the app modules/ folder because
> > modules that user absolute imports cannot find their dependencies.
> > This does not reload modules and one is forced to user conditional
> > reloads when debugging modules.
>
> > The solution
> > =========
>
> > I found and implemented a better way. With the code in trunk we can
> > now do:
>
> > d = local_import('a.b.c')
>
> > - it is not based on exec
> > - it searches in applicaitons/currentapp/modules/ before searching in
> > sys.path so no conflicts ever
> > - each modules/ folder acts like its own site-packages and you can put
> > any third party module in there whether or not is uses relative
> > imports
> > - you can ask it force reloading modules at every request, great for
> > debugging modules:
>
> > d = local_import('a.b.c', force=True)
>
> > This opens the door to better plugins implemented (partially) as
> > modules.
>
> > Please check it out and report any success/failure. If ok it will be
> > in 1.70.1
>
> > Massimo
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
