Re: [Sugar-devel] [Dextrose] [PATCH sugar-toolkit] Insert activity root path in front of the reset of sys.path
Excerpts from Aleksey Lim's message of Sun Feb 06 01:50:54 +0100 2011: [Posting only on sugar-devel - please let's discuss general Sugar development just there, not on dextrose] Otherwise it is possible to include, eg, system modules before local ones. Which is how Python 2 usually works. Your patch would make us deviate from upstream, making it harder to debug. It might even cause regressions in existing activities that bundle copies of system modules for use on older systems. If we prefer the bundled copy over the system one, it might break on more recent systems. In Restore [1] I'm taking care to change the name of the file [2] and use it only if the system copy is too old, but other authors might not have been that careful. I'd much rather see us mention this in the documentation than unconditionally messing with the module loading order for all activities. AFAICT Python 3 prefers local modules over the system ones [4], so this is only a matter of time resp. of a Py3k / g-i / Gnome3 based Sugar port. Sascha [1] http://activities.sugarlabs.org/en-US/sugar/addon/4327 [2] http://git.sugarlabs.org/restore/mainline/blobs/master/zipfile26.py [3] http://git.sugarlabs.org/restore/mainline/blobs/master/restore.py#line29 [4] http://diveintopython3.org/your-first-python-program.html#importsearchpath -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH sugar-toolkit] Insert activity root path in front of the reset of sys.path
On Mon, Feb 7, 2011 at 4:40 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Otherwise it is possible to include, eg, system modules before local ones. Which is how Python 2 usually works. Your patch would make us deviate from upstream, making it harder to debug. I've done extensive programming with Python, Perl, PHP and similar scripting languages over the last, um, 14 years. Local modules/libs always override system ones. To wit, note the first entry at $ python Python 2.7 (r27:82500, Sep 16 2010, 18:03:06) [GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2 Type help, copyright, credits or license for more information. import sys sys.path ['', '/usr/lib/python27.zip', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/lib/python2.7/site-packages', '/usr/lib/python2.7/site-packages/PIL', '/usr/lib/python2.7/site-packages/gst-0.10', '/usr/lib/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info', '/usr/lib/python2.7/site-packages/webkit-1.0'] The library the developer meant to include is a lot easier to debug (to the developer involved) than system library changed API subtly/silently/in a relnote encoded with a reference to a bug number. The behaviour sought by Aleksey's patch makes sense. I am surprised that CWD isn't set to SUGAR_BUNDLE_PATH, maybe that needs to get fixed instead. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH sugar-toolkit] Insert activity root path in front of the reset of sys.path
On Sun, 2011-02-06 at 00:50 +, Aleksey Lim wrote: Otherwise it is possible to include, eg, system modules before local ones. Seems like a good idea. Reviewed-by: Bernie Innocenti ber...@codewiz.org -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH sugar-toolkit] Insert activity root path in front of the reset of sys.path
Not that would cause much of a slowdown, or that this would handle the (hopefully unlikely) case where Python gains modules named identically to Activity ones, but: What are we trying to solve here? Are activities bundling third-party Python libraries which have to be preferred in most cases over system-provided ones (if present)? Wouldn't it be better to ensure Activity developers make proper use of namespaces when developing them instead? On 2/6/2011 5:58 PM, Bernie Innocenti wrote: On Sun, 2011-02-06 at 00:50 +, Aleksey Lim wrote: Otherwise it is possible to include, eg, system modules before local ones. Seems like a good idea. Reviewed-by: Bernie Innocentiber...@codewiz.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH sugar-toolkit] Insert activity root path in front of the reset of sys.path
On Sun, 2011-02-06 at 19:22 -0500, Samuel Greenfeld wrote: What are we trying to solve here? Are activities bundling third-party Python libraries which have to be preferred in most cases over system-provided ones (if present)? So, my expectations is that if an activity developer chooses to bundle a python module with the activity, it means that the version shipped with the system was too old, or inadequate for some reason. For example, a game could require a newer version of pygame. It's a common technique for portability. Sometimes the system version works better than the bundled version, but since Sugar has no way to tell, the safest strategy is letting the activities decide. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH sugar-toolkit] Insert activity root path in front of the reset of sys.path
On Sun, Feb 06, 2011 at 07:22:12PM -0500, Samuel Greenfeld wrote: Not that would cause much of a slowdown, or that this would handle the (hopefully unlikely) case where Python gains modules named identically to Activity ones, but: What are we trying to solve here? Are activities bundling third-party Python libraries which have to be preferred in most cases over system-provided ones (if present)? In my mind, the situation when modules that come with activity have higher priority than system ones is more natural/predictable. Actually, the problem that triggered the issue in my case was screen.py module, if pexpect(that has /screen.py) is not installed FlipSticks works well. But if pexpect is installed, FlipSticks magically stops working. Wouldn't it be better to ensure Activity developers make proper use of namespaces when developing them instead? On 2/6/2011 5:58 PM, Bernie Innocenti wrote: On Sun, 2011-02-06 at 00:50 +, Aleksey Lim wrote: Otherwise it is possible to include, eg, system modules before local ones. Seems like a good idea. Reviewed-by: Bernie Innocentiber...@codewiz.org -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH sugar-toolkit] Insert activity root path in front of the reset of sys.path
On Sun, Feb 6, 2011 at 9:39 PM, Aleksey Lim alsr...@activitycentral.org wrote: On Sun, Feb 06, 2011 at 07:22:12PM -0500, Samuel Greenfeld wrote: Not that would cause much of a slowdown, or that this would handle the (hopefully unlikely) case where Python gains modules named identically to Activity ones, but: What are we trying to solve here? Are activities bundling third-party Python libraries which have to be preferred in most cases over system-provided ones (if present)? In my mind, the situation when modules that come with activity have higher priority than system ones is more natural/predictable. ACK -- seen this happen in other projects before. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH sugar-toolkit] Insert activity root path in front of the reset of sys.path
On 02/06/2011 09:39 PM, Aleksey Lim wrote: In my mind, the situation when modules that come with activity have higher priority than system ones is more natural/predictable. I attempted to do the reverse with Watch Me. Watch Me includes binary python modules that are not installed by default in OLPC's builds, so Watch Me includes binaries, but the binaries only work on Fedora 9 (OLPC 8.2.*, I think). Therefore, it also includes a shim layer that ensures that the bundled binary modules always have lower priority than system-installed modules if they are installed. So I recommend not assuming that the priority only goes one way. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH sugar-toolkit] Insert activity root path in front of the reset of sys.path
On Mon, Feb 07, 2011 at 12:13:24AM -0500, Benjamin M. Schwartz wrote: On 02/06/2011 09:39 PM, Aleksey Lim wrote: In my mind, the situation when modules that come with activity have higher priority than system ones is more natural/predictable. I attempted to do the reverse with Watch Me. Watch Me includes binary python modules that are not installed by default in OLPC's builds, so Watch Me includes binaries, but the binaries only work on Fedora 9 (OLPC 8.2.*, I think). Therefore, it also includes a shim layer that ensures that the bundled binary modules always have lower priority than system-installed modules if they are installed. So I recommend not assuming that the priority only goes one way. The question is what (FlipSticks vs WatchMe) usecase is more usual and what fails are more unpredictable :). In my mind, when people are coding end applications whey should not care about names of modules (assuming that local modules will be imported in any case) they are creating (in case of comparing with coding libraries). In cases like WatchMe (in my mind special cases), it is all time possible to change sys.path in particular way before including the rest of WatchMe code. On other side, having requirement to do something special for regular activities, sounds overkill. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
