Am 25.03.2014 um 23:43 schrieb Uwe Stöhr <uwesto...@web.de>: > Am 25.03.2014 07:40, schrieb Stephan Witt: > >> I did it and I cannot see what is wrong with "Python detection is not the >> task of the installer." > > Before LyX 2.0.5 the installer did not come in every case with a > stripped-down Python. The installer has to define LyX's PATH_prefix otherwise > LyX would not be functional. > For LyX 2.0.4 and older it worked this way: > - the installer checks for an existing Python installation > - if there is any, add its path to LyX's PATH_prefix > - if not, install a stripped down Python and add its path to LyX's > PATH_prefix. > > Now the installer _always_ installs a stripped down Python for LyX and adds > its path to PATH_prefix.
I have to repeat myself: I think it's not the task of the installer to add anything to path_prefix. > >> Because LyX is unusable without it LyX should use the correct python >> detection itself. > > That would be nice. I don't know if this can be achieved because checking for > installed programs require some registry routines. > However the discussion I recently had with Georg on the list about Python I have seen Georg's messages and I think Georg didn't say the current solution is working fine. He mentioned a bug he filed which is not solved until now. > showed my that the current solution should work fine and hopefully there will > no user complain about Python issues on Windows - we will see after the > release of LyX 2.1 final. > >> On Unix this was simply using the PATH. > > A program can be in the PATH but in many cases they don't. Therefore on > Windows it is looking first in the registry section HKLM. Look there first in > the list of programs and if nothing is found, look in the list of programs > that can be uninstalled. If still nothing is found look in the registry > section HKCU. > > > Since python 3 is more common the lookup is >> a little bit more complicated. If using PATH isn't the right thing on >> Windows then it >> has to be done in the Windows way from inside the LyX binary itself. >> Unfortunately >> it's not possible to use python for this task… If providing a bundled python >> installation >> is an acceptable alternative solution then do it this way. > > I already do this and to be able to implement your feature I will have to do > the same with ImageMagick and Ghostscript. I thought about it today again and > I think that is in general no problem since the installer would not be larger > (it already contains stripped-down versions), LyX would then only require > about 20 MB more disk space which should not be a problem anymore. > BUT people might complain that LyX is not using their Ghostscript of > ImageMagick. For example some prefer the 64bit version of Ghostscript but in > the installer I can only bundle the 32bit version to assure that LyX will > work on all Windows PCs. I therefore would like to ask the users what they > think. > Hmm, OK, we could nevertheless implement your feature and look of Ghostscript > is a problem or not when old preferences are copied. I only want to assure > that your feature is not going in for LyX 2.1 to assure that we don't copy > preferences from LyX 2.0.4 and older for the described Python issue that can > occur. If the path to Ghostscript is wrong after copying the preferences, LyX > is still usable, only PDF and EPS images cannot be shown inside LyX and we > can react the quickly and remove the feature if this should really be > necessary. > > Is that OK with you? We completely agree. The way it works on Windows now is not subject to change, IMO. It may change when the python lookup works on Windows without installer code. The way it works on Mac is different, the existing user prefs will be copied. Stephan
