Should modjy call imp.load("site")?

[Alan Kennedy-2]

Hi all,

There's a bug report which I'm not sure how to handle.

http://bugs.jython.org/issue1473

It basically states that modjy should call imp.load("site") on startup.

But from what I can see, site is only about processing .pth files,
which modjy already supports, by processing all .pth files that it
finds inside the "WEB-INF/lib-python" directory. (The rather elegant
(IMHO) "WEB-INF/lib-python" solution was suggested by Leo when he was
working on the Django-on-jython project: I think it works well).

Any thoughts on whether modjy should implement this change?

Regards,

Alan.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

[Colin Evans-2]

Hi Alan,
I submitted the bug because without calling imp.load("site"), packages  
in Lib/site-packages cannot be imported.  I currently use modjy  with  
Jetty, and pull in jython.jar and the associated libraries via Jetty's  
'extraClasspath' context variable, using my system's installed Jython  
instance.  This environment works better for a tight edit-and-run  
cycle, and also allows us to use the same Jython configuration for our  
non-jetty-based software.

It would be great if modjy could support a variety of import schemes.  
It doesn't appear that importing site will break any other existing  
functionality and will also bring modjy in line with standard Python  
2.5 behavior where site is supposed to be automatically imported:

http://www.python.org/doc/2.5/lib/module-site.html

Thanks!
Colin


On Oct 6, 2009, at 10:46 AM, Alan Kennedy wrote:

> Hi all,
>
> There's a bug report which I'm not sure how to handle.
>
> http://bugs.jython.org/issue1473
>
> It basically states that modjy should call imp.load("site") on  
> startup.
>
> But from what I can see, site is only about processing .pth files,
> which modjy already supports, by processing all .pth files that it
> finds inside the "WEB-INF/lib-python" directory. (The rather elegant
> (IMHO) "WEB-INF/lib-python" solution was suggested by Leo when he was
> working on the Django-on-jython project: I think it works well).
>
> Any thoughts on whether modjy should implement this change?
>
> Regards,
>
> Alan.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

[Alan Kennedy-2]

[Colin]

> I submitted the bug because without calling imp.load("site"), packages in
> Lib/site-packages cannot be imported.  I currently use modjy  with Jetty,
> and pull in jython.jar and the associated libraries via Jetty's
> 'extraClasspath' context variable, using my system's installed Jython
> instance.  This environment works better for a tight edit-and-run cycle, and
> also allows us to use the same Jython configuration for our non-jetty-based
> software.
>
> It would be great if modjy could support a variety of import schemes.  It
> doesn't appear that importing site will break any other existing
> functionality and will also bring modjy in line with standard Python 2.5
> behavior where site is supposed to be automatically imported:
>
> http://www.python.org/doc/2.5/lib/module-site.html

OK, I see the problem now.

But I think that it should not be standard behaviour; I'd prefer to
make it optional behaviour, so that it doesn't interfere with WAR
deployments.

So if a "load-site-packages" option, is specified, then
imp.load("site) takes place.

How does that sound?

Alan.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

[Colin Evans-2]

Hi Alan,
That sounds like a good solution for me.  Thanks for your help!

One question - what do you see as the ideal development configuration  
using modjy + pylons?  I used snakefight, and although it works great  
for deployment, it is too slow for a fast debug-run cycle.  It sounds  
like the solution that I pulled together isn't the same as what other  
folks are using.

Thanks
Colin


On Oct 6, 2009, at 11:45 AM, Alan Kennedy wrote:

> [Colin]
>> I submitted the bug because without calling imp.load("site"),  
>> packages in
>> Lib/site-packages cannot be imported.  I currently use modjy  with  
>> Jetty,
>> and pull in jython.jar and the associated libraries via Jetty's
>> 'extraClasspath' context variable, using my system's installed Jython
>> instance.  This environment works better for a tight edit-and-run  
>> cycle, and
>> also allows us to use the same Jython configuration for our non-
>> jetty-based
>> software.
>>
>> It would be great if modjy could support a variety of import  
>> schemes.  It
>> doesn't appear that importing site will break any other existing
>> functionality and will also bring modjy in line with standard  
>> Python 2.5
>> behavior where site is supposed to be automatically imported:
>>
>> http://www.python.org/doc/2.5/lib/module-site.html
>
> OK, I see the problem now.
>
> But I think that it should not be standard behaviour; I'd prefer to
> make it optional behaviour, so that it doesn't interfere with WAR
> deployments.
>
> So if a "load-site-packages" option, is specified, then
> imp.load("site) takes place.
>
> How does that sound?
>
> Alan.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

[Philip Jenvey-3]

On Oct 6, 2009, at 10:46 AM, Alan Kennedy wrote:

> Hi all,
>
> There's a bug report which I'm not sure how to handle.
>
> http://bugs.jython.org/issue1473
>
> It basically states that modjy should call imp.load("site") on  
> startup.
>
> But from what I can see, site is only about processing .pth files,
> which modjy already supports, by processing all .pth files that it
> finds inside the "WEB-INF/lib-python" directory. (The rather elegant
> (IMHO) "WEB-INF/lib-python" solution was suggested by Leo when he was
> working on the Django-on-jython project: I think it works well).
>
> Any thoughts on whether modjy should implement this change?

We briefly talked about this a while ago now -- we pretty much came to  
a conclusion but the actual change fell through the cracks

We were thinking that creating a new PythonInterpreter should  
automatically load site unless you've set a property to disable it.  
This is what CPython does when you create an interpreter in an  
embedded fashion. It also matches the command line behavior more  
closely.

Then modjy doesn't have to be involved. Right now it's somewhat  
duplicating some of the functionality of site.py (like for .pth  
support), ideally it wouldn't do any of that. Though I'm not sure how  
usable it would be if the site option was disabled and it didn't do  
any .pth support or the like.

This would have been an easier change to swallow for the 2.5 release  
-- changing PythonInterpreter now is a little intrusive. Though I  
think it'd be worth it, and that most users of modjy would want site  
to be implicitly imported.

--
Philip Jenvey

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

[Alan Kennedy-2]

[Philip]

> We were thinking that creating a new PythonInterpreter should automatically
> load site unless you've set a property to disable it. This is what CPython
> does when you create an interpreter in an embedded fashion. It also matches
> the command line behavior more closely.
>
> Then modjy doesn't have to be involved. Right now it's somewhat duplicating
> some of the functionality of site.py (like for .pth support), ideally it
> wouldn't do any of that. Though I'm not sure how usable it would be if the
> site option was disabled and it didn't do any .pth support or the like.
>
> This would have been an easier change to swallow for the 2.5 release --
> changing PythonInterpreter now is a little intrusive. Though I think it'd be
> worth it, and that most users of modjy would want site to be implicitly
> imported.

Well, I've pretty much implemented the change for optionally loading
site packages, with the option defaulting to false.

The reason why is because I'm concerned about how this might affect
standalone WAR deployment: just being conservative I suppose.

What do you think of that solution?

Alan.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

[Leo Soto M.]

2009/10/6 Alan Kennedy <jython-dev@...>:

> [Colin]
>> I submitted the bug because without calling imp.load("site"), packages in
>> Lib/site-packages cannot be imported.  I currently use modjy  with Jetty,
>> and pull in jython.jar and the associated libraries via Jetty's
>> 'extraClasspath' context variable, using my system's installed Jython
>> instance.  This environment works better for a tight edit-and-run cycle, and
>> also allows us to use the same Jython configuration for our non-jetty-based
>> software.
>>
>> It would be great if modjy could support a variety of import schemes.  It
>> doesn't appear that importing site will break any other existing
>> functionality and will also bring modjy in line with standard Python 2.5
>> behavior where site is supposed to be automatically imported:
>>
>> http://www.python.org/doc/2.5/lib/module-site.html
>
> OK, I see the problem now.
>
> But I think that it should not be standard behaviour; I'd prefer to
> make it optional behaviour, so that it doesn't interfere with WAR
> deployments.

Out of curiosity: Why would it interfere with WAR deployments?

[I'm the most interested on keeping the stand-alone WAR deployments
working, but not realizing why importing site would break them make me
feel stupid ;-)]

--
Leo Soto M.
http://blog.leosoto.com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

[Alan Kennedy-2]

[Alan]
>> But I think that it should not be standard behaviour; I'd prefer to
>> make it optional behaviour, so that it doesn't interfere with WAR
>> deployments.

[Leo]
> Out of curiosity: Why would it interfere with WAR deployments?
>
> [I'm the most interested on keeping the stand-alone WAR deployments
> working, but not realizing why importing site would break them make me
> feel stupid ;-)]

Indeed, that is the key question.

My thinking is that importing site i.e. processing Lib/site-packages,
would require a jython installation on the machine, i.e. an absolute
setting for python.home.

But I suppose that if python.home is set to WEB-INF/lib-python, then
the site import should still work.

I'm leaning now to having a "load_site_packages" parameter, but
defaulting it to true, to emulate the behaviour of the interactive
interpreter as much as possible.

Any further thoughts, or objections, before I go checking this in?

Alan.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

[Leo Soto M.]

On Wed, Oct 7, 2009 at 9:45 AM, Alan Kennedy <jython-dev@...> wrote:

[Alan]
> > > But I think that it should not be standard behaviour; I'd prefer to
> > > make it optional behaviour, so that it doesn't interfere with WAR
> > > deployments.
>

[Leo]
> > Out of curiosity: Why would it interfere with WAR deployments?
> >
> > [I'm the most interested on keeping the stand-alone WAR deployments
> > working, but not realizing why importing site would break them make me
> > feel stupid ;-)]

[Alan]

> Indeed, that is the key question.
>
> My thinking is that importing site i.e. processing Lib/site-packages,
> would require a jython installation on the machine, i.e. an absolute
> setting for python.home.
>
> But I suppose that if python.home is set to WEB-INF/lib-python, then
> the site import should still work.
>
> I'm leaning now to having a "load_site_packages" parameter, but
> defaulting it to true, to emulate the behaviour of the interactive
> interpreter as much as possible.
>
> Any further thoughts, or objections, before I go checking this in?

Not from me. I'll test if doj WAR deployment have any issue with the
change later (but before 2.5.2, of course).

Regards,
--
Leo Soto M.
http://blog.leosoto.com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

[Philip Jenvey-3]

On Oct 7, 2009, at 6:45 AM, Alan Kennedy wrote:

> [Alan]
>>> But I think that it should not be standard behaviour; I'd prefer to
>>> make it optional behaviour, so that it doesn't interfere with WAR
>>> deployments.
>
> [Leo]
>> Out of curiosity: Why would it interfere with WAR deployments?
>>
>> [I'm the most interested on keeping the stand-alone WAR deployments
>> working, but not realizing why importing site would break them make  
>> me
>> feel stupid ;-)]
>
> Indeed, that is the key question.
>
> My thinking is that importing site i.e. processing Lib/site-packages,
> would require a jython installation on the machine, i.e. an absolute
> setting for python.home.
>
> But I suppose that if python.home is set to WEB-INF/lib-python, then
> the site import should still work.
>
> I'm leaning now to having a "load_site_packages" parameter, but
> defaulting it to true, to emulate the behaviour of the interactive
> interpreter as much as possible.
>
> Any further thoughts, or objections, before I go checking this in?

What's the value of sys.prefix normally under modjy?

--
Philip Jenvey


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

[Alan Kennedy-2]

[Philip]
> What's the value of sys.prefix normally under modjy?

Sorry for the delay in getting back about this.

The following applies to Tomcat 5.5 and 6.0, on Windows.

If "python.home" is set to an absolute path, then the sys.prefix is
set to that path, e.g. "C:\jython2.5.1".

If "python.home" is set to a relative path inside the WEB-INF
directory, e.g. "WEB-INF/lib-python", sys.prefix is set to an absolute
path to that directory, but relative to the directory from which the
tomcat server was started, i.e.
"C:\apache-tomcat\bin\WEB-INF\lib-python".

If "python.home" is not set at all, then sys.prefix is an absolute
path to (presumably) whichever directory jython.jar is in, e.g.
"C:\apache-tomcat\webapps\modjy_webapp\WEB-INF\lib".

As I mentioned before, I have the modification written and tested to
add support for imp.load("site"), under optional control, with the
option defaulting to true, i.e. same behaviour as the "-S" command
line switch.

I'm trying to think of reasons not to check it in. I suppose that a
possible clash with modjy's existing ".pth" file support is one reason
not to.

Another option is that I could close this bug as "Not a bug", and ask
the submitter to use the existing .pth support to reference all of the
site-packages required.

http://bugs.jython.org/issue1473

Regards,

Alan.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev