Issue2706

classification
Title: Use python.path instead of JYTHONPATH
Type: behaviour Severity: minor
Components: Versions: Jython 2.7
Milestone:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: jeff.allen Nosy List: jeff.allen, zyasoft
Priority: normal Keywords: patch

Created on 2018-09-23.13:41:06 by jeff.allen, last changed 2019-01-02.09:11:22 by jeff.allen.

Messages
msg12118 (view) Author: Jeff Allen (jeff.allen) Date: 2018-09-23.13:41:04
The environment variable JYTHONPATH determines the search path for Python code outside the standard library, in the way PYTHONPATH does for CPython. Incorrectly, it is not ignored when the -E option is given to the jython command. I propose to move its initialisation to org.python.util.jython at the same stage other variables are handled coverted to registry entries.

This will have the side effect that JYTHONPATH will no longer affect Java applications that create their own interpreter (only the property python.path does that). I think this is good, but may also be an unexpected change.

Rationale:

TL;DR: consistency; original design intent.

It its original design, Jython took configuration only from the Java Properties (read from the registry files and java -D options), not from environment variables. Published books tell us this is how it works, and Java discourages reliance on environment variables (https://docs.oracle.com/javase/tutorial/essential/environment/env.html). And it is mostly still true, except that JYTHONPATH is sampled in the middle of initialisation, in all circumstances, and overrides any -Dpython.path=value given to Java. For a pure Java application to rid itself of an inappropriate external JYTHONPATH it has to set python.path in the "post-properties" during initialisation.

It seems ok that jython.main() should pay attention to (certain) environment variables: it's a command used from the shell, and users can turn it off with the -E option. The similarity to CPython is good. There is a well-defined place for environment variables in the "pecking order" with other sources which JYTHONPATH slightly diverges from.
msg12120 (view) Author: Jeff Allen (jeff.allen) Date: 2018-09-24.05:48:55
I have tested this idea and had to make two changes in test_java_integration, where running a proxy now looks like:

            cmd = [os.path.join(System.getProperty("java.home"), "bin", "java"),
                   "-Dpython.path=" + os.path.dirname(__file__),
                   "-classpath", classpath, "BarkTheDog"]
            ...
                subprocess.check_output(cmd, universal_newlines=True, stderr=subprocess.STDOUT)

It's shorter as we do not have to prepare JYTHONPATH in a clone of os.environ.

Because we might decide it is a bad idea, I'm parking it here as a patch, rather than committing it directly.
msg12162 (view) Author: Jeff Allen (jeff.allen) Date: 2018-10-26.18:23:26
Committed so we can evaluate in more contexts: https://hg.python.org/jython/rev/4057a7c55133
History
Date User Action Args
2019-01-02 09:11:22jeff.allensetstatus: pending -> closed
resolution: accepted -> fixed
2018-10-26 18:23:26jeff.allensetstatus: open -> pending
assignee: jeff.allen
resolution: accepted
messages: + msg12162
2018-10-26 18:22:30jeff.allensetfiles: - iss2706-JYTHONPATH.patch
2018-09-24 05:48:57jeff.allensetfiles: + iss2706-JYTHONPATH.patch
keywords: + patch
messages: + msg12120
2018-09-23 13:41:06jeff.allencreate