From: Chris N. <cni...@fo...> - 2013-03-07 18:24:43
|
Hi all, I'm attempting to use Inline::Python in a webmin module. I can execute the script from the command line and things go just fine: I am able to bind to the Python lib and create objects based on Python classes, etc. Once I add code to the script to load up the required webmin prereqs, the problems start. I end up with an error like this: "Can't locate object method "new" via package "FooBar" (perhaps you forgot to load "FooBar"?)" Where "FooBar" is the Perl name for a Python class "foobar". For some reason it looks like maybe @INC is not correct the second time around, but I cannot confirm that. Could it be that Inline compiles the library in one location, but somehow there is a change relative to that location once inside of the webmin environment? Any thoughts on what's going on? Kind Regards, Chris |
From: Jamie C. <jca...@we...> - 2013-03-07 18:45:40
|
On 07/Mar/2013 09:57 Chris Nighswonger <cni...@fo...> wrote .. > Hi all, > > I'm attempting to use Inline::Python in a webmin module. > > I can execute the script from the command line and things go just fine: I > am able to bind to the Python lib and create objects based on Python > classes, etc. > > Once I add code to the script to load up the required webmin prereqs, the > problems start. I end up with an error like this: > > "Can't locate object method "new" via package "FooBar" (perhaps you forgot > to load "FooBar"?)" > > Where "FooBar" is the Perl name for a Python class "foobar". > > For some reason it looks like maybe @INC is not correct the second time > around, but I cannot confirm that. > > Could it be that Inline compiles the library in one location, but somehow > there is a change relative to that location once inside of the webmin > environment? > > Any thoughts on what's going on? It could be that Webmin is modifying @INC, such as when you call code in another Webmin module. You mentioned that this only happens when you call the webmin pre-reqs .. which specific line of code triggers the problem? - Jamie |
From: Chris N. <cni...@fo...> - 2013-03-08 13:07:40
|
On Thu, Mar 7, 2013 at 1:45 PM, Jamie Cameron <jca...@we...> wrote: > > On 07/Mar/2013 09:57 Chris Nighswonger <cni...@fo...> wrote .. <snip> > > > > "Can't locate object method "new" via package "FooBar" (perhaps you forgot > > to load "FooBar"?)" > > > > Where "FooBar" is the Perl name for a Python class "foobar". <snip> > > It could be that Webmin is modifying @INC, such as when you call code > in another Webmin module. You mentioned that this only happens when you > call the webmin pre-reqs .. which specific line of code triggers the problem? It happens when I call init_config() A brief reading of that sub seems to indicate plenty of potential for some sort of change which would result in the problem I'm seeing. Exactly what it is, I don't know. Kind Regards, Chris |
From: Chris N. <cni...@fo...> - 2013-03-08 14:19:39
|
On Fri, Mar 8, 2013 at 8:07 AM, Chris Nighswonger <cni...@fo...> wrote: > It happens when I call init_config() > > A brief reading of that sub seems to indicate plenty of potential for > some sort of change which would result in the problem I'm seeing. > Exactly what it is, I don't know. > Ok. I finally got my environment setup to execute my Webmin module cgi's from the cli. It is not init_config(). The script produces the expected results when called from the cli. It errors out when loaded into the browser with: Can't locate object method "new" via package "FooBar" (perhaps you forgot to load "FooBar"?) at ./my_module-lib.pl line 64. It may be something with miniserv rather than Webmin proper. I can write a script which does not load/require any code related to Webmin or my module, but uses Inline in the same fashion. This script will also run from the cli, but errors in the exact same way when served by miniserv. Kind Regards, Chris |
From: Chris N. <cni...@fo...> - 2013-03-08 15:21:47
|
On Fri, Mar 8, 2013 at 9:19 AM, Chris Nighswonger <cni...@fo...> wrote: > On Fri, Mar 8, 2013 at 8:07 AM, Chris Nighswonger > <cni...@fo...> wrote: > > It may be something with miniserv rather than Webmin proper. I can > write a script which does not load/require any code related to Webmin > or my module, but uses Inline in the same fashion. This script will > also run from the cli, but errors in the exact same way when served by > miniserv. Sorry for replying to myself again. Things appear to go bad with the eval block here: https://github.com/webmin/webmin/blob/master/miniserv.pl#L2337 So I'm guessing that its a problem with the environment in which the eval is executed. Though what it is, I am unsure. Kind Regards, Chris |
From: Chris N. <cni...@fo...> - 2013-03-08 17:02:24
|
On Fri, Mar 8, 2013 at 10:21 AM, Chris Nighswonger <cni...@fo...> wrote: > So I'm guessing that its a problem with the environment in which the > eval is executed. Though what it is, I am unsure. Further testing indicates that the problem is environment, but not due to anything Webmin is/isn't doing. Writing an extremely simplified script using Inline::Python and a couple of simple Python functions within the Perl script itself proved to work as expected both within and without Webmin. The problem arises when including external Python libs in Perl scripts. I'm guessing that Inline::Python has to call the Python interpreter at some point. Maybe when this happens, the environment is not setup correctly for Python to locate the required libs. So sorry for the false alarm. I'll follow up with the fix if I find it since someone else may want to use Inline in their Webmin modules at some point. Kind Regards, Chris |
From: Jamie C. <jca...@we...> - 2013-03-08 18:08:09
|
On 08/Mar/2013 07:21 Chris Nighswonger <cni...@fo...> wrote .. > On Fri, Mar 8, 2013 at 9:19 AM, Chris Nighswonger > <cni...@fo...> wrote: > > On Fri, Mar 8, 2013 at 8:07 AM, Chris Nighswonger > > <cni...@fo...> wrote: > > > > It may be something with miniserv rather than Webmin proper. I can > > write a script which does not load/require any code related to Webmin > > or my module, but uses Inline in the same fashion. This script will > > also run from the cli, but errors in the exact same way when served by > > miniserv. > > Sorry for replying to myself again. > > Things appear to go bad with the eval block here: > > https://github.com/webmin/webmin/blob/master/miniserv.pl#L2337 > > So I'm guessing that its a problem with the environment in which the > eval is executed. Though what it is, I am unsure. Perhaps forcing a change of package (as happens in that block) is the cause of the problem? - Jamie |
From: Chris N. <cni...@fo...> - 2013-03-08 18:36:10
|
On Fri, Mar 8, 2013 at 1:07 PM, Jamie Cameron <jca...@we...> wrote: > On 08/Mar/2013 07:21 Chris Nighswonger <cni...@fo...> wrote .. >> >> Things appear to go bad with the eval block here: >> >> https://github.com/webmin/webmin/blob/master/miniserv.pl#L2337 >> >> So I'm guessing that its a problem with the environment in which the >> eval is executed. Though what it is, I am unsure. > > Perhaps forcing a change of package (as happens in that block) is the > cause of the problem? I thought the same thing. So I ran a one-liner from the cli doing and eval and forcing a package change. Sure enough: it threw the same error. Sadly, though, when I commented out the package change in miniserv, it still borked. Also, when using the very simple script in which the actual Python was embedded, forcing a package change made no difference. The simple script worked either way. Kind Regards, Chris |
From: Chris N. <cni...@fo...> - 2013-03-08 18:49:25
|
On Fri, Mar 8, 2013 at 1:35 PM, Chris Nighswonger <cni...@fo...> wrote: > On Fri, Mar 8, 2013 at 1:07 PM, Jamie Cameron <jca...@we...> wrote: >> >> Perhaps forcing a change of package (as happens in that block) is the >> cause of the problem? > > I thought the same thing. So I ran a one-liner from the cli doing and > eval and forcing a package change. Sure enough: it threw the same > error. Sadly, though, when I commented out the package change in > miniserv, it still borked. > > Also, when using the very simple script in which the actual Python was > embedded, forcing a package change made no difference. The simple > script worked either way. When I force the module cgi script to be executed in the root user's env (by changing the shebang line to #!/usr/bin/env /usr/bin/perl), it works and miniserv borks due to the lack of headers (which is what I would expect). So something must differ from root's environment in the environment miniserv executes the script in. At present I don't see any significant difference, however. Kind Regards, Chris |