"python bin\kalite" should not switch interpreter unless required.

[MCGallaspy]

Currently if the environment variable KALITE_PYTHON is set, then bin\kalite will use that interpreter even if invoked with a different one -- does it make sense to have the interpreter set in this order?

1. The interpreter it's invoked with
2. The value of KALITE_PYTHON if it exists
3. Whatever the system does normally when bin\kalite is executed without an interpreter (using the #! or whatever)

This is an issue on windows -- my personal workflow is to use bin\windows\kalite.bat when I wish to use KALITE_PYTHON, but sometimes (in e.g. a virtualenv) I would like to specify the interpreter.

[66eli77]

I feel like my wrongly permanently set KALITE_PYTHON and KALITE_DIR is caused from a very early on Mac kalite installer, since then, I need to unset these environment variables very time.
It might be good to capture the error caused by these variables and do a automatic reset for them.

[MCGallaspy]

At least in windows, these variables are set during installation and unset during uninstallation -- can we institute a similar thing for mac, if it doesn't already exist? Otherwise it sounds like you just need to unset these variables for good, or set them to more appropriate values for your system. But yeah, it may be possible to have a graceful fallback if they're not set appropriately. Do you have any suggestions for graceful behavior on error, @66eli77?

[66eli77]

if these two variables can be auto reset, I think anything wrong with these two variables should not stop the user from starting kalite.

[66eli77]

If they cannot be auto reset, prompt and teach the user how to reset these two variables.

[benjaoming]

Well, the thing is that @jamalex once informed me that there were systems where the default python will point to python3, and thus we are forcing python2 if it's there. I admit that we could be doing other things.

But IMO it all boils down to a case of being too clever. Hence the issue.

@MCGallaspy what's the use case for this btw?

I'd like to remove this behaviour, because I think that systems where python is python3 could potentially just do python2 /usr/bin/kalite.

[MCGallaspy]

@66eli77 that's not very specific -- what exactly was wrong with the values you had set? That could clue in to what the best behavior on an error is. Rather than unset an environment variable, which takes control of the environment out of the user's hands, I think it's preferable to show a warning and have some fallback behavior.

@benjaoming the use case I stated was this:

my personal workflow is to use bin\windows\kalite.bat when I wish to use KALITE_PYTHON, but sometimes (in e.g. a virtualenv) I would like to specify the interpreter.

Sometimes I would like to use the interpreter in the environment variable, but sometimes I want to specify it like this and override the value of the environment variable: C:\Some\Path\python.exe bin\kalite foo

[66eli77]

@MCGallaspy the fallback behavior I mentioned above is to auto reset the values and not stop the user from starting the server.

[cpauya]

Hi @66eli77, sorry, yes the KALITE_PYTHON and KALITE_DIR env vars have been set by an earlier version of the Mac installer and wasn't cleaned.

Please check and delete the following files:

1. /Library/LaunchDaemons/org.learningequality.kalite.plist -- This is the destination of the old installer and is most likely causing your issue.
2. /Library/LaunchAgents/org.learningequality.kalite.plist -- This is where the current installer puts the .plist file.

You can safely delete any of them because the new OSX installer will re-create it on the /Library/LaunchAgents/ directory.

After deleting, please restart OSX and check if those env vars are still there.

The current installer now provides a way to "clean" these env vars thru the Preferences Window -> Advanced tab -> Reset App button.

Just a note that the OSX app will check the KALITE_PYTHON value if it doesn't exist or the path is invalid.

[benjaoming]

I think that these workflow-related requests that can be solved with local scripts and aliases should be done so as far as possible as explained in #4312.

It's clear that this one has become a little more annoying that necessary because of the forced overwriting of the Python interpreter as explained above, and it would be great if we could stop doing that... but I think we're steering the ship clear of any such radical changes from now on.

[benjaoming]

Hmm, if it's really important to get PyPy support, we should fix this......

[benjaoming]

This simple and yet possibly breaking change would be nice to get into 0.17 since we're moving to PEX on the OSX installer anyways.

[benjaoming]

Fixed in 0.17, releasing at the end of October. But work on installers can start now with the prerelease of 0.17b1.