If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

For Python-based xulrunner applications, PyXPCOM should support 'embedded Python' (run standalone, ignoring whatever Python install may be present locally)



Other Applications
12 years ago
8 years ago


(Reporter: Geoff Schmidt, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: n/a


Consider a xulrunner application that uses PyXPCOM, and attempts to ship with an embedded copy of Python so it runs even if Python is not installed. Because of the way PyXPCOM initializes Python, if Python is installed on the local machine, code from that local copy of Python will imported and run before any Python code written by the user has a chance to intervene, and so the application will get a 'chimera' of the user's Python installation and the Python that shipped with the application. Worse, for reasons I don't fully understand, if Python is not installed, PyXPCOM will fail to start. The attached patch adds a pref that tells PyXPCOM to (try to convince Python to) ignore any Python modules in the standard  locations and use the ones in {bin}/python instead.


I am working on a tool (a Python distutils extension) to convert a tree of Python code and XUL resources into a standalone xulrunner-based GUI application that can run on any machine, whether it has Mozilla and Python installed or not. We're using the current version of this to package the Windows port of Participatory Culture Foundation's "DTV" application, which is a user-friendly "internet TV" client. [www.participatoryculture.org; dtvmac.com]

I've attached the PyXPCOM patch that I'm using for this so far. It determines whether to run in embedded mode from a preference. If the preference is set, it adjusts Python's expected directory layout accordingly -- please see the patch for commentary on how this is accomplished, as it's a bit of a mess. If the preference is not set, the behavior should be unchanged.

The expectation is that you would use this patch in conjunction with a packaging tool like I've written, which runs a Python package dependency scanner as py2exe and py2app do and builds one unified tree with all of the Python code needed, including whatever parts of the standard library are necessary. Then the packaging tool plops this into {bin}/python, which is already where PyXPCOM looks for Python code.

Help needed:

This works great on Windows. But on Unix-like platforms, it needs an extra #ifdef case to be written to set an environment variable. The problem is that I have an nsString containing a path, and I need to set the PYTHONPATH environment  variable to that path. On Unix-like platforms, the environment isn't Unicode, so the path needs to be encoded in whatever encoding the filesystem is expecting. I don't know the right way to do this. Any help out there?

Reproducible: Always

Steps to Reproduce:

Comment 1

12 years ago
Created attachment 210406 [details] [diff] [review]
My first stab. Needs cases for setting the environment on platforms other than Windows.

Comment 2

11 years ago
prefs will not be sufficient to deal with all the issues around embedding python in a xulrunner distribution.  You have to deal with this issue through a number of methods, some compile time, some install time.  I've added Trent to the CC list, he can better describe the various elements that have to happen to make embedding python work.  They include things such as:

registry entries for pywin32
rpath modification on linux (install location dependent)
linkage path for Python.framework on osx

Comment 3

10 years ago
mass reassigning to nobody.
Assignee: dougt → nobody


8 years ago
Component: XPCOM → PyXPCOM
Product: Core → Other Applications
QA Contact: xpcom → pyxpcom
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.