Closed Bug 307553 Opened 19 years ago Closed 6 years ago

pyxpcom needs to pass program name to Python runtime, XRE needs to provide that

Categories

(Other Applications Graveyard :: PyXPCOM, defect)

Product:
Other Applications Graveyard
Component:
PyXPCOM
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: trentm, Unassigned)

Details

Attachments

(1 file)

patch for XRE to provide XRE_APP_PROGRAM_NAME path, and to PyXPCOM to set Py_SetProgramName
4.15 KB, patch
benjamin
: review-
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

PyXPCOM should call Py_SetProgramName() before initializing the Python runtime
via Py_Initialize. The running program name is used by the Python runtime to
properly set Python's "sys.executable". On Windows and the Mac Python can and
does use system APIs to get this info. However, on Linux/Solaris/Un*x it needs
the program name (or argv[0] directly).

When PyXPCOM is being loaded it doesn't have access to argv[0] from the XRE
runtime stuff. I have a patch to add a dir property to nsXREDirProvider
(XRE_APP_PROGRAM_NAME) to provide this. The patch also has the beginnings of a
patch to PyXPCOM to get the program name and call Py_SetProgramName().

I'd appreciate some comments on:
- where to best put this code in PyXPCOM (PyXPCOM calls Py_Initialize() in two
other places)
- whether the toolkit/xre/... changes look alright

After that I'll add something to the PyXPCOM test cases to get and print
sys.exectuable.

Reproducible: Always

Steps to Reproduce:
This should probably be assigned to MarkH but I don't have perms to change the
owner. Could someone do that?
Patch against Mozilla 1.8 to have the XRE directory provider provide the
program name (as calculated by XRE_GetBinaryPath()) as XRE_APP_PROGRAM_NAME and
to PyXPCOM to get that and call Python's Py_SetProgramPath().
Is this XRE key supposed to return the actual binary that is running (the
xulrunner binary) or something else? What about embedding situations where we
might not know the binary name (does it matter then)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 195308 [details] [diff] [review]
patch for XRE to provide XRE_APP_PROGRAM_NAME path, and to PyXPCOM to set Py_SetProgramName

This is correct for windows/linux, but it is *not* correct on mac, where we
trick argv[0]. See
http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsAppRunner.cpp#1885
Attachment #195308 - Flags: review-
> Is this XRE key supposed to return the actual binary that is running (the
> xulrunner binary) or something else? 

That's right the actual binary.

> What about embedding situations where we
> might not know the binary name (does it matter then)?

It looks like the right thing to do would be to deal with dirSvc->Get()
returning a failure condition? Thoughts?

It isn't a killer for the Python runtime if it doesn't know the binary name.
Just an inconvenience for Python code that may want to use "sys.executable". To
wit: PyXPCOM works just fine on Linux now eventhough this info isn't getting
through.

Trent points out I was wrong about gBinaryPath, because that hack is inside
XRE_GetBinaryPath. So I suppose the code as written is generally ok. However, I
would prefer this were named XRE_XULRUNNER_BINARY, not XRE_APP_PROGRAM_NAME, and
documented explicitly that way. Also document that this key will not be
available when libxul is embedded (using XRE_InitEmbedding).
> However, I would prefer this were named XRE_XULRUNNER_BINARY, not 
> XRE_APP_PROGRAM_NAME

I'm fine with changing that name. How about XRE_BINARY_PATH to compare well to
the XRE_BINARY_PATH environment variable and the XRE_GetBinarPath() function? Or
perhaps something *slightly* different than the env. var. to avoid confusion
would be preferable, say, XRE_APP_BINARY_PATH?

 

The "APP" is the problem. This is not the "app" binary, this is the xulrunner
binary. I actually intend to do something XRE_APP_BINARY_PATH-esque which will
be significantly different (the path to the xulrunner app stub binary).
But "XRE" != "xulrunner", right?, so "XULRUNNER" isn't exactly right either. For
example, XRE-based apps like Firefox and Komodo and Thunderbird are not currently 
currently using xulrunner. (Correct me if I am wrong, I'm not that up on
xulrunner's current state.)

Is "XRE_BINARY_PATH" acceptable? Too confusing with the env var of the same
name? Confusing with the env var and that's perfect?

> I actually intend to do something XRE_APP_BINARY_PATH-esque which will
> be significantly different

...or is XRE_GetBinaryPath() going to change to no longer be the real running
binary for xulrunner-based apps?


XRE_GetBinaryPath is probably not going to change (it's not frozen yet, but I
don't forsee significant changes).

The whole xre/xulrunner thing is confusing, but I think we are going to want two
different keys:

                        "standalone" Firefox   Xulrunner-based firefox

XRE_XULRUNNER_BINARY    path to firefox.exe    path to xulrunner.exe
XRE_APP_BINARY          path to firefox.exe    path to (stub) firefox.exe

I don't know which one of these pyxpcom eventually wants to use (since I'm not
exactly sure what sys.executable is typically used for within python).
> but I think we are going to want two different keys

Okay, sounds reasonable.
1. Should those defs be appended with _FILE to match other similar ones:
   http://lxr.mozilla.org/mozilla1.8/source/xpcom/io/nsDirectoryServiceDefs.h
   http://lxr.mozilla.org/mozilla1.8/source/xpcom/io/nsAppDirectoryServiceDefs.h

2. Can you point me in the right direction for getting what
XRE_XULRUNNER_BINARY[_FILE] should be? Then I'll whip up a patch.


> I don't know which one of these pyxpcom eventually wants to use

Benjamin,
xulrunner-newbie question: With a xulrunner-based apps is the actual running
binary "firefox.exe" (or other app) or "xulrunner.exe"?


> 1. Should those defs be appended with _FILE to match other similar ones:

If you like. It doesn't matter to me.

> 2. Can you point me in the right direction for getting what
> XRE_XULRUNNER_BINARY[_FILE] should be? Then I'll whip up a patch.

The code you have already written should do what you want. XRE_APP_BINARY is the
"hard" one, you do not need to worry about it.

> xulrunner-newbie question: With a xulrunner-based apps is the actual running
> binary "firefox.exe" (or other app) or "xulrunner.exe"?

The firefox.exe is just a little stub file that sets up the evironment and then
launches xulrunner.exe (xulrunner.exe is the main executable).
Flags: blocking1.9a1?
Its not clear to me which one Python should use.  There is no clear definition of what sys.executable means (ie, some apps may use it to launch another copy of themself, while others may use it to attempt to locate a process name, for example).
Status: NEW → ASSIGNED
Flags: blocking1.9a1? → blocking1.9-
mass reassigning to nobody.
Assignee: dougt → nobody
Status: ASSIGNED → NEW
Component: XPCOM → PyXPCOM
Product: Core → Other Applications
QA Contact: xpcom → pyxpcom
Version: Trunk → unspecified
(In reply to comment #13)
> Its not clear to me which one Python should use.  There is no clear definition
> of what sys.executable means (ie, some apps may use it to launch another copy
> of themself, while others may use it to attempt to locate a process name, for
> example).

See this thread: http://mail.python.org/pipermail/python-dev/2006-March/062453.html
in which Trent says (http://mail.python.org/pipermail/python-dev/2006-March/062466.html) that PyXPCOM follows the same interpretation as py2exe, namely that sys.executable is used to find the exe that is currently
running.

It seems the current state (as at xulrunner 1.9.1.3) is that sys.executable on Linux is still empty - and so is sys.argv - it would be great to move forward on this...
I really don't think sys.argv should be present in the PyXPCOM embedded case: XULRunner doesn't maintain a single command line, handling is done via nsICommandLineHandler and there is automatic remoting.
(In reply to comment #16)
> I really don't think sys.argv should be present in the PyXPCOM embedded case:
> XULRunner doesn't maintain a single command line, handling is done via
> nsICommandLineHandler and there is automatic remoting.

Fair enough, but sys.executable could still be provided on Linux to match other platforms...

so it seems the only remaining issue with the patch was with changing the constant name, correct?
Component is obsolete so resolving bugs as INCOMPLETE[B
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: