Re: master: Python detection on Mac doesn't find python 2.7.15
On Friday, 28 June 2019 08.56.14 WEST Kornel Benko wrote: > Done at 2a37ad9c. > > Kornel Thank you to both. :-) -- José Abílio
Re: master: Python detection on Mac doesn't find python 2.7.15
Am Freitag, 28. Juni 2019, 00:11:47 CEST schrieb Jean-Marc Lasgouttes: > Le 26/06/2019 à 15:56, José Abílio Matos a écrit : > > There are three places to change: > > > > * os::python23 function in support; > > * autotools support; > > * cmake; > > > > We should be simply a matter of replacing 3.3 by 3.5. > > I did the two first ones, I let Kornel do cmake. > > JMarc > Done at 2a37ad9c. Kornel signature.asc Description: This is a digitally signed message part.
Re: master: Python detection on Mac doesn't find python 2.7.15
Le 26/06/2019 à 15:56, José Abílio Matos a écrit : There are three places to change: * os::python23 function in support; * autotools support; * cmake; We should be simply a matter of replacing 3.3 by 3.5. I did the two first ones, I let Kornel do cmake. JMarc
Re: master: Python detection on Mac doesn't find python 2.7.15
Am Donnerstag, 27. Juni 2019, 14:56:05 CEST schrieb Stephan Witt: > Am 27.06.2019 um 09:03 schrieb Kornel Benko : > > > > Am Mittwoch, 26. Juni 2019, 17:45:28 CEST schrieb Stephan Witt: > >> Am 26.06.2019 um 14:08 schrieb Kornel Benko : > >>> > >>> Am Mittwoch, 26. Juni 2019, 13:21:25 CEST schrieb Stephan Witt: > > I’m not surprised at these explanation. > > > > The real world scenario would be to disable python 3.4 on my system > > and test it with 2.7.15 - this works for me. > > > > But - if it’s clear LyX doesn’t work with python 3.4 why is it tried > > and used? > > Or is it this what you propose? Change the tested minimal python > > version from 3.3.0 to 3.5.0? > > Then I’ll cannot agree more. > > The attached patch works for me on Mac. > > Stephan > > >>> > >>> The patch (and the original) omits to work with python2.7? > >> > >> AFAICS it refuses to work with python < 2.7 > >> (But works with e.g. 1.9 :) ???) > >> > >>> I have not seen problems (cmake build allows 2.7 version) > >>> > >>> My versions are 2.7.12 and 3.5.2. > >> > >> For me it works with 2.7.15 > >> > >> Stephan > >> > >> > > > > But that means that our python-selection is not correct. > > You're referring to my 1.9 note? I cannot think of a system with python < > 2.0… > It was a nit-picking joke perhaps. I cannot test it :) No, I am referring to code that accepts 2.0 trough 2.8, but only 2.7 should be OK. > > We have to test for 2.7 and 3.5+ IMHO. > > The code accepts 2.7 IMO. And rejects 3.2.x ATM but accepts 3.3. > The idea is to change the test for 3.3 and raise the limit to 3.5. This, and the test for 2.7 only IMHO. > Stephan Kornel signature.asc Description: This is a digitally signed message part.
Re: master: Python detection on Mac doesn't find python 2.7.15
Am 27.06.2019 um 09:03 schrieb Kornel Benko : > > Am Mittwoch, 26. Juni 2019, 17:45:28 CEST schrieb Stephan Witt: >> Am 26.06.2019 um 14:08 schrieb Kornel Benko : >>> >>> Am Mittwoch, 26. Juni 2019, 13:21:25 CEST schrieb Stephan Witt: > I’m not surprised at these explanation. > > The real world scenario would be to disable python 3.4 on my system > and test it with 2.7.15 - this works for me. > > But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and > used? > Or is it this what you propose? Change the tested minimal python version > from 3.3.0 to 3.5.0? > Then I’ll cannot agree more. The attached patch works for me on Mac. Stephan >>> >>> The patch (and the original) omits to work with python2.7? >> >> AFAICS it refuses to work with python < 2.7 >> (But works with e.g. 1.9 :) ???) >> >>> I have not seen problems (cmake build allows 2.7 version) >>> >>> My versions are 2.7.12 and 3.5.2. >> >> For me it works with 2.7.15 >> >> Stephan >> >> > > But that means that our python-selection is not correct. You're referring to my 1.9 note? I cannot think of a system with python < 2.0… It was a nit-picking joke perhaps. I cannot test it :) > We have to test for 2.7 and 3.5+ IMHO. The code accepts 2.7 IMO. And rejects 3.2.x ATM but accepts 3.3. The idea is to change the test for 3.3 and raise the limit to 3.5. Stephan
Re: master: Python detection on Mac doesn't find python 2.7.15
Am Mittwoch, 26. Juni 2019, 17:45:28 CEST schrieb Stephan Witt: > Am 26.06.2019 um 14:08 schrieb Kornel Benko : > > > > Am Mittwoch, 26. Juni 2019, 13:21:25 CEST schrieb Stephan Witt: > >>> I’m not surprised at these explanation. > >>> > >>> The real world scenario would be to disable python 3.4 on my system > >>> and test it with 2.7.15 - this works for me. > >>> > >>> But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and > >>> used? > >>> Or is it this what you propose? Change the tested minimal python version > >>> from 3.3.0 to 3.5.0? > >>> Then I’ll cannot agree more. > >> > >> The attached patch works for me on Mac. > >> > >> Stephan > >> > > > > The patch (and the original) omits to work with python2.7? > > AFAICS it refuses to work with python < 2.7 > (But works with e.g. 1.9 :) ???) > > > I have not seen problems (cmake build allows 2.7 version) > > > > My versions are 2.7.12 and 3.5.2. > > For me it works with 2.7.15 > > Stephan > > But that means that our python-selection is not correct. We have to test for 2.7 and 3.5+ IMHO. Kornel signature.asc Description: This is a digitally signed message part.
Re: master: Python detection on Mac doesn't find python 2.7.15
Am 26.06.2019 um 14:08 schrieb Kornel Benko : > > Am Mittwoch, 26. Juni 2019, 13:21:25 CEST schrieb Stephan Witt: >>> I’m not surprised at these explanation. >>> >>> The real world scenario would be to disable python 3.4 on my system >>> and test it with 2.7.15 - this works for me. >>> >>> But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and >>> used? >>> Or is it this what you propose? Change the tested minimal python version >>> from 3.3.0 to 3.5.0? >>> Then I’ll cannot agree more. >> >> The attached patch works for me on Mac. >> >> Stephan >> > > The patch (and the original) omits to work with python2.7? AFAICS it refuses to work with python < 2.7 (But works with e.g. 1.9 :) ???) > I have not seen problems (cmake build allows 2.7 version) > > My versions are 2.7.12 and 3.5.2. For me it works with 2.7.15 Stephan
Re: master: Python detection on Mac doesn't find python 2.7.15
On Wednesday, 26 June 2019 13.08.37 WEST Kornel Benko wrote: > The patch (and the original) omits to work with python2.7? > I have not seen problems (cmake build allows 2.7 version) > > My versions are 2.7.12 and 3.5.2. > > Kornel They should I have tested them with 2.7 (.16 in my case). -- José Abílio
Re: master: Python detection on Mac doesn't find python 2.7.15
On Wednesday, 26 June 2019 11.40.07 WEST Stephan Witt wrote: > Hi José, > > I’m not surprised at these explanation. > > The real world scenario would be to disable python 3.4 on my system > and test it with 2.7.15 - this works for me. That is what I am proposing. :-) > But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and > used? Or is it this what you propose? Change the tested minimal python > version from 3.3.0 to 3.5.0? Then I’ll cannot agree more. That is also my point. At some point during the process we settled on python 3.3 because it supports the u"" notation. In python 2 those mean unicode strings (strings with an encoding as to differentiate them from the usual "" strings that are basically an array of bytes). In python 3 u"" is a no-op because all the strings have an encoding associated. Until python 3.3 the u"" notation gave an error. Again this notation was introduced to allow an easy migration to python 3 by using a common code base. It is the same reasoning as in the previous case. So I am really proposing is to accept as the minimum version for python 3 the 3.5 release. There are three places to change: * os::python23 function in support; * autotools support; * cmake; We should be simply a matter of replacing 3.3 by 3.5. > Best regards, > Stephan -- José Abílio
Re: master: Python detection on Mac doesn't find python 2.7.15
Am Mittwoch, 26. Juni 2019, 13:21:25 CEST schrieb Stephan Witt: > > I’m not surprised at these explanation. > > > > The real world scenario would be to disable python 3.4 on my system > > and test it with 2.7.15 - this works for me. > > > > But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and > > used? > > Or is it this what you propose? Change the tested minimal python version > > from 3.3.0 to 3.5.0? > > Then I’ll cannot agree more. > > The attached patch works for me on Mac. > > Stephan > The patch (and the original) omits to work with python2.7? I have not seen problems (cmake build allows 2.7 version) My versions are 2.7.12 and 3.5.2. Kornel signature.asc Description: This is a digitally signed message part.
Re: master: Python detection on Mac doesn't find python 2.7.15
Am 26.06.2019 um 12:40 schrieb Stephan Witt :
>
> Am 26.06.2019 um 10:46 schrieb José Abílio Matos :
>>
>> On Tuesday, 25 June 2019 19.17.13 WEST Stephan Witt wrote:
>>> +checking list of modules...
>>> /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/layouts/fix
>>> me.module Traceback (most recent call last):
>>> File
>>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>>> .py", line 1875, in checkModulesConfig()
>>> File
>>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>>> .py", line 1495, in checkModulesConfig retval = processModuleFile(file,
>>> filename.encode('ascii'), bool_docbook) File
>>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>>> .py", line 1594, in processModuleFile % (modname, filename, desc, pkgs, req,
>>> excl, catgy, local))
>>> TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'
>>>
>>> Best regards,
>>> Stephan
>>
>> Thank you Stefan,
>> these results make all the sense to me.
>>
>> This problem only occurs in python 3.4, it works for 3.5+.
>>
>> TLDR; I honestly suggest that the minimum python 3 version supported to be
>> python 3.5.
>>
>>
>> The long explanation:
>>
>> For those that have been following the threads regarding python 3 and LyX
>> the
>> main topic is always the same.
>>
>> When python 3 was released in 2008 (really!) there was a wish to drop some
>> features and to fix long standing design decisions on python.
>>
>> It worked is most cases. But in some cases those changes went too far, and
>> thus all the issues regarding the transition from python 2 to python 3.
>>
>> At some point, if you remember I said that in a sense python 2 and python 3
>> were different languages. And I maintain what I said at that time.
>>
>> One motto of python (for versions 2 and 3) though is:
>>
>> $ python3 -m this | grep purity
>> Although practicality beats purity.
>>
>> $ python2 -m this | grep purity
>> Although practicality beats purity.
>>
>> So the practical side won and the successive python 3 versions brought more
>> and more features to support the python 2 transition.
>>
>> The last part of these came with python 3.5, and in one cases is related
>> with
>> the interpolation of byte strings. The feature that works similarly to
>> fprintf
>> and friends in C/C++.
>>
>> The % operator, used to work only on strings (that have a defined encoding)
>> and not in sequence of bytes. That decision was by design. The main issue is
>> that sometimes we are working on text files for which we do not know the
>> encoding but we know that they have ascii.
>>
>> This applies a lot to lyx files before 1.6, but not only.
>>
>> After too many complains the decision was reverted in python 3.5. That
>> allows
>> for the same code to run in both python 2 (that does not distinguishes
>> between
>> strings and sequences of bytes) and in python 3.
>>
>> In this particular case we can track all the cases where this feature is
>> used
>> and ensure that the alternative works for both python 2(.7) and for python 3.
>>
>> My suggestion as in other messages this year is simply to bump the
>> requirement
>> to python 3.5 and live with it.
>>
>> Best regards,
>>
>> PS: the above is technically correct but you should take the philosophical/
>> technical considerations with a grain of salt. After all the language name
>> comes from the "Monty Python Flying Circus" and no one is expecting the
>> Spanish Inquisition. :-) :-D
>
> Hi José,
>
> I’m not surprised at these explanation.
>
> The real world scenario would be to disable python 3.4 on my system
> and test it with 2.7.15 - this works for me.
>
> But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and
> used?
> Or is it this what you propose? Change the tested minimal python version from
> 3.3.0 to 3.5.0?
> Then I’ll cannot agree more.
The attached patch works for me on Mac.
Stephan
The terminal output is:
$ /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/MacOS/lyx -v
Running: python3 -c 'from __future__ import print_function;import sys;
print(sys.version_info[:2], end="")'
sh: python3: command not found
Looking for python 3.x ...
Examining /opt/local/bin/python3.4
Running: /opt/local/bin/python3.4 -c 'from __future__ import
print_function;import sys; print(sys.version_info[:2], end="")'
Examining /opt/local/bin/python3.4-config
Running: /opt/local/bin/python3.4-config -c 'from __future__ import
print_function;import sys; print(sys.version_info[:2], end="")'
Usage: /opt/local/bin/python3.4-config
[--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir]
Examining /opt/local/bin/python3.4m
Running: /opt/local/bin/python3.4m -c 'from __future__ import
print_function;import sys; print(sys.version_info[:2], end="")'
Examining /opt/local/bin/python3.4m-config
Running: /opt/local/bin/python3.4m-
Re: master: Python detection on Mac doesn't find python 2.7.15
Am 26.06.2019 um 10:46 schrieb José Abílio Matos :
>
> On Tuesday, 25 June 2019 19.17.13 WEST Stephan Witt wrote:
>> +checking list of modules...
>> /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/layouts/fix
>> me.module Traceback (most recent call last):
>> File
>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>> .py", line 1875, in checkModulesConfig()
>> File
>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>> .py", line 1495, in checkModulesConfig retval = processModuleFile(file,
>> filename.encode('ascii'), bool_docbook) File
>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>> .py", line 1594, in processModuleFile % (modname, filename, desc, pkgs, req,
>> excl, catgy, local))
>> TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'
>>
>> Best regards,
>> Stephan
>
> Thank you Stefan,
> these results make all the sense to me.
>
> This problem only occurs in python 3.4, it works for 3.5+.
>
> TLDR; I honestly suggest that the minimum python 3 version supported to be
> python 3.5.
>
>
> The long explanation:
>
> For those that have been following the threads regarding python 3 and LyX the
> main topic is always the same.
>
> When python 3 was released in 2008 (really!) there was a wish to drop some
> features and to fix long standing design decisions on python.
>
> It worked is most cases. But in some cases those changes went too far, and
> thus all the issues regarding the transition from python 2 to python 3.
>
> At some point, if you remember I said that in a sense python 2 and python 3
> were different languages. And I maintain what I said at that time.
>
> One motto of python (for versions 2 and 3) though is:
>
> $ python3 -m this | grep purity
> Although practicality beats purity.
>
> $ python2 -m this | grep purity
> Although practicality beats purity.
>
> So the practical side won and the successive python 3 versions brought more
> and more features to support the python 2 transition.
>
> The last part of these came with python 3.5, and in one cases is related with
> the interpolation of byte strings. The feature that works similarly to
> fprintf
> and friends in C/C++.
>
> The % operator, used to work only on strings (that have a defined encoding)
> and not in sequence of bytes. That decision was by design. The main issue is
> that sometimes we are working on text files for which we do not know the
> encoding but we know that they have ascii.
>
> This applies a lot to lyx files before 1.6, but not only.
>
> After too many complains the decision was reverted in python 3.5. That allows
> for the same code to run in both python 2 (that does not distinguishes
> between
> strings and sequences of bytes) and in python 3.
>
> In this particular case we can track all the cases where this feature is used
> and ensure that the alternative works for both python 2(.7) and for python 3.
>
> My suggestion as in other messages this year is simply to bump the
> requirement
> to python 3.5 and live with it.
>
> Best regards,
>
> PS: the above is technically correct but you should take the philosophical/
> technical considerations with a grain of salt. After all the language name
> comes from the "Monty Python Flying Circus" and no one is expecting the
> Spanish Inquisition. :-) :-D
Hi José,
I’m not surprised at these explanation.
The real world scenario would be to disable python 3.4 on my system
and test it with 2.7.15 - this works for me.
But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and used?
Or is it this what you propose? Change the tested minimal python version from
3.3.0 to 3.5.0?
Then I’ll cannot agree more.
Best regards,
Stephan
Re: master: Python detection on Mac doesn't find python 2.7.15
On Tuesday, 25 June 2019 19.17.13 WEST Stephan Witt wrote:
> +checking list of modules...
> /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/layouts/fix
> me.module Traceback (most recent call last):
> File
> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
> .py", line 1875, in checkModulesConfig()
> File
> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
> .py", line 1495, in checkModulesConfig retval = processModuleFile(file,
> filename.encode('ascii'), bool_docbook) File
> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
> .py", line 1594, in processModuleFile % (modname, filename, desc, pkgs, req,
> excl, catgy, local))
> TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'
>
> Best regards,
> Stephan
Thank you Stefan,
these results make all the sense to me.
This problem only occurs in python 3.4, it works for 3.5+.
TLDR; I honestly suggest that the minimum python 3 version supported to be
python 3.5.
The long explanation:
For those that have been following the threads regarding python 3 and LyX the
main topic is always the same.
When python 3 was released in 2008 (really!) there was a wish to drop some
features and to fix long standing design decisions on python.
It worked is most cases. But in some cases those changes went too far, and
thus all the issues regarding the transition from python 2 to python 3.
At some point, if you remember I said that in a sense python 2 and python 3
were different languages. And I maintain what I said at that time.
One motto of python (for versions 2 and 3) though is:
$ python3 -m this | grep purity
Although practicality beats purity.
$ python2 -m this | grep purity
Although practicality beats purity.
So the practical side won and the successive python 3 versions brought more
and more features to support the python 2 transition.
The last part of these came with python 3.5, and in one cases is related with
the interpolation of byte strings. The feature that works similarly to fprintf
and friends in C/C++.
The % operator, used to work only on strings (that have a defined encoding)
and not in sequence of bytes. That decision was by design. The main issue is
that sometimes we are working on text files for which we do not know the
encoding but we know that they have ascii.
This applies a lot to lyx files before 1.6, but not only.
After too many complains the decision was reverted in python 3.5. That allows
for the same code to run in both python 2 (that does not distinguishes between
strings and sequences of bytes) and in python 3.
In this particular case we can track all the cases where this feature is used
and ensure that the alternative works for both python 2(.7) and for python 3.
My suggestion as in other messages this year is simply to bump the requirement
to python 3.5 and live with it.
Best regards,
PS: the above is technically correct but you should take the philosophical/
technical considerations with a grain of salt. After all the language name
comes from the "Monty Python Flying Circus" and no one is expecting the
Spanish Inquisition. :-) :-D
--
José Abílio
Re: master: Python detection on Mac doesn't find python 2.7.15
Am 25.06.2019 um 12:04 schrieb Jean-Marc Lasgouttes
:
>
> Le 17/06/2019 à 20:10, José Abílio Matos a écrit :
>> On Monday, 17 June 2019 17.55.02 WEST you wrote:
>>> That is what I would do, but I was waiting for a directive from José.
>>>
>>> JMarc
>> You are both right. :-)
>> Adding python in the last position will work, and is the right thing to do.
>> Please try then lyx from the command line using the -v option to see what is
>> the output. I would like to see if the python detection at run time is
>> working
>> on Mac.
>
> I just noticed that this answer from José went directly to me.
>
> Stephan, I add the 'python' to configure and you answer José request, right ?
> ;)
>
> JMarc
I can build a LyX package again.
This is what happens on startup here:
$ /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/MacOS/lyx -v
Running: python3 -c 'from __future__ import print_function;import sys;
print(sys.version_info[:2], end="")'
sh: python3: command not found
Looking for python 3.x ...
Examining /opt/local/bin/python3.4
Running: /opt/local/bin/python3.4 -c 'from __future__ import
print_function;import sys; print(sys.version_info[:2], end="")'
Found Python (3, 4)
LyX: Konfiguriere das Benutzerverzeichnis neu
Running: /opt/local/bin/python3.4 -tt
"/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure.py"
--with-version-suffix=-2.4
--binary-dir="/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/MacOS/"
checking for a Latex2e program...
+checking for "latex"... yes
...
+Indexing TeX files...
Indexing files of type cls
Indexing files of type sty
Indexing files of type bst
Indexing files of type bib
Indexing files of type bbx
Indexing files of type cbx
done
+checking list of modules...
/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/layouts/fixme.module
Traceback (most recent call last):
File
"/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure.py",
line 1875, in
checkModulesConfig()
File
"/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure.py",
line 1495, in checkModulesConfig
retval = processModuleFile(file, filename.encode('ascii'), bool_docbook)
File
"/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure.py",
line 1594, in processModuleFile
% (modname, filename, desc, pkgs, req, excl, catgy, local))
TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'
Best regards,
Stephan
Re: master: Python detection on Mac doesn't find python 2.7.15
Le 17/06/2019 à 20:10, José Abílio Matos a écrit : On Monday, 17 June 2019 17.55.02 WEST you wrote: That is what I would do, but I was waiting for a directive from José. JMarc You are both right. :-) Adding python in the last position will work, and is the right thing to do. Please try then lyx from the command line using the -v option to see what is the output. I would like to see if the python detection at run time is working on Mac. I just noticed that this answer from José went directly to me. Stephan, I add the 'python' to configure and you answer José request, right ? ;) JMarc
Re: master: Python detection on Mac doesn't find python 2.7.15
Le 17/06/2019 à 18:43, Stephan Witt a écrit : Hi JMarc, to answer my question myself: it’s the change d933d72fa9e. There isn’t python2 nor python3 on a Mac. Wouldn’t it be an option to check for python too? Like the attached patch… That is what I would do, but I was waiting for a directive from José. JMarc
Re: master: Python detection on Mac doesn't find python 2.7.15
Hi JMarc, to answer my question myself: it’s the change d933d72fa9e. There isn’t python2 nor python3 on a Mac. Wouldn’t it be an option to check for python too? Like the attached patch… Stephan > Am 17.06.2019 um 17:09 schrieb Stephan Witt : > > Hi, > > I’ve tried to check out the latest changes on master. > > Currently the build fails to find a proper python: > > configuring LyX version 2.4.0dev > checking for build type... release > checking for version suffix... -[2.4 > checking whether Qt5 is disabled... no > checking build system type... x86_64-apple-darwin18.6.0 > checking host system type... x86_64-apple-darwin18.6.0 > checking target system type... x86_64-apple-darwin18.6.0 > checking what packaging should be used... macosx > checking whether to enable maintainer-specific portions of Makefiles... no > checking whether make supports nested variables... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /opt/local/bin/gmkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether UID '501' is supported by ustar format... yes > checking whether GID '20' is supported by ustar format... yes > checking how to create a ustar tar archive... gnutar > checking for a Python interpreter with version >= 2.7.0 or 3.3.0... none > configure: error: no suitable Python interpreter found > > Here I have python 2.7.15: > > $ python -V > Python 2.7.15 > > $ python -c 'import sys; version = sys.version_info[:3]; sys.exit(not > ((2,7,0) <= version < (3,0,0) or version >= (3,3,0)))' > $ echo $? > 0 > > What should I do? > > Bets regards, > Stephan check4python.patch Description: Binary data
master: Python detection on Mac doesn't find python 2.7.15
Hi, I’ve tried to check out the latest changes on master. Currently the build fails to find a proper python: configuring LyX version 2.4.0dev checking for build type... release checking for version suffix... -[2.4 checking whether Qt5 is disabled... no checking build system type... x86_64-apple-darwin18.6.0 checking host system type... x86_64-apple-darwin18.6.0 checking target system type... x86_64-apple-darwin18.6.0 checking what packaging should be used... macosx checking whether to enable maintainer-specific portions of Makefiles... no checking whether make supports nested variables... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /opt/local/bin/gmkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether UID '501' is supported by ustar format... yes checking whether GID '20' is supported by ustar format... yes checking how to create a ustar tar archive... gnutar checking for a Python interpreter with version >= 2.7.0 or 3.3.0... none configure: error: no suitable Python interpreter found Here I have python 2.7.15: $ python -V Python 2.7.15 $ python -c 'import sys; version = sys.version_info[:3]; sys.exit(not ((2,7,0) <= version < (3,0,0) or version >= (3,3,0)))' $ echo $? 0 What should I do? Bets regards, Stephan
Re: Re: Re: Re: Re: Re: Python detection
On Saturday 13 April 2013 16:37:55 Pavel Sanda wrote: > facepalm.jpg By using a polar bear instead of a cat you have spoken to my heart. ;-) Cheers, -- José Abílio
Re: Re: Python detection
On Saturday 13 April 2013 16:53:42 Richard Heck wrote:
> Isn't there some "import __future__" thing we can use to make this easy?
> Or is that what is only in 2.7?
>
> Richard
python 2.7 supports both "from future import " as well as new features that
were backported from python 3 (specifically from 3.1) such as python 2.6 as
incorporated features from python 3.0
That why I said that it possible to write code that is compatible between
python 2.7 and python 3, if necessary using 2to3 as Günter referred before.
FWIW http://docs.python.org/dev/whatsnew/ (with a list of what has changed
between each version) is a nice read.
One example that illustrates my point, in lib/scripts/lyxpak.py we use sets
(data structures, basically dictionaries where we only care about keys).
In python 3 a set can be declared as
{1,2,3,4,5}
and so can you using python 2.7.
In a sense this is a bad example because the previous syntax would still work
set([1,2,3,4,5]) but I hope you get the point. :-)
--
José Abílio
Re: Re: Re: Re: Re: Python detection
José Matos wrote: > Oh, BTW and then if we go with python 3.x we can call the next version lyx > 3.0. :-D > Or we can already adopt the firefox convention and go with lyx-3.0 for new > release. :-) 195.113.26.193/~sanda/facepalm.jpg :D
Re: Re: Re: Re: Re: Python detection
On Saturday 13 April 2013 11:36:18 Pavel Sanda wrote: > José Matos wrote: > > In the mean time it is possible to use the features of python 2.7 that > > allow an easy update to python 3.3. > > I hope we already at least support python 2.7, cause what I see in > changelogs, Uwe already ships it in Win version :) Sure, lyx works with python 2.7 but it does not make any use of the new features that are present in python-2.7 but are not present in python-2.4. That is the point of forward compatible. :-) When I say that we should support python-2.7 I mean, in this context, that we should make python-2.7 the minimum supported version in order to simplify a transition to python 3 later. > > Note that even if we go python 3 we should set a minimum version, like say > > python 3.2 or even python 3.3 if we are feeling lucky. :-) > > You mean that backward compatibility issues are even within 3.x series? No. Not with that alarming tone. :-) I mean that it is easy to go from python-2.7 to python-3.3 (or 3.2) that it is to go from python-2.7 to python-3.0 or python-3.1. Take as an example the python 3.3 release: http://www.python.org/getit/releases/3.3.0/ Notice the third paragraph: "Python 3.3 includes a range of improvements of the 3.x series, as well as *easier porting* between 2.x and 3.x." In the development of python 3.3 there was a moratorium in the development of new language features in order to improve both the standard library and the porting of the code from 2.x. > > Note that personally I have no problem going the python 3 route and if we > > decide to go that way I will support it. > > I don't feel any hurry for bumping, just tried to catch you while your are > active, otherwise I'm not sure who wants to do that... > > Pavel Note that I am proposing this change after lyx-2.1 is released so in a sense this discussion is premature. Oh, BTW and then if we go with python 3.x we can call the next version lyx 3.0. :-D Or we can already adopt the firefox convention and go with lyx-3.0 for new release. :-) FWIW on a more serious note that are lots of very competent python programmers in this list so I am not worried. :-) Regards, -- José Abílio
Re: Python detection
On 04/13/2013 02:09 PM, José Matos wrote: On Friday 12 April 2013 18:09:02 Pavel Sanda wrote: I thought we want to be >3.0 compatible and ditch 2.x series completely(?). Otherwise it looks like just maintenace burden without profit. What's the status of python 3 on fedora/debian/suse? Pavel In the mean time it is possible to use the features of python 2.7 that allow an easy update to python 3.3. Note that even if we go python 3 we should set a minimum version, like say python 3.2 or even python 3.3 if we are feeling lucky. :-) In case of Fedora it has the most recent versions python 2.7.4 and python 3.3.1 (they are in the testing stage because it has been released this/last week). The distribution default is yet python 2 and it will be at least for another year. Note that personally I have no problem going the python 3 route and if we decide to go that way I will support it. Isn't there some "import __future__" thing we can use to make this easy? Or is that what is only in 2.7? Richard
Re: Re: Re: Re: Python detection
José Matos wrote: > In the mean time it is possible to use the features of python 2.7 that allow > an easy update to python 3.3. I hope we already at least support python 2.7, cause what I see in changelogs, Uwe already ships it in Win version :) > Note that even if we go python 3 we should set a minimum version, like say > python 3.2 or even python 3.3 if we are feeling lucky. :-) You mean that backward compatibility issues are even within 3.x series? > Note that personally I have no problem going the python 3 route and if we > decide to go that way I will support it. I don't feel any hurry for bumping, just tried to catch you while your are active, otherwise I'm not sure who wants to do that... Pavel
Re: Re: Re: Re: Python detection
On Friday 12 April 2013 18:09:02 Pavel Sanda wrote: > I thought we want to be >3.0 compatible and ditch 2.x series completely(?). > Otherwise it looks like just maintenace burden without profit. > > What's the status of python 3 on fedora/debian/suse? > > Pavel In the mean time it is possible to use the features of python 2.7 that allow an easy update to python 3.3. Note that even if we go python 3 we should set a minimum version, like say python 3.2 or even python 3.3 if we are feeling lucky. :-) In case of Fedora it has the most recent versions python 2.7.4 and python 3.3.1 (they are in the testing stage because it has been released this/last week). The distribution default is yet python 2 and it will be at least for another year. Note that personally I have no problem going the python 3 route and if we decide to go that way I will support it. -- José Abílio
Re: Python detection
On 2013-04-13, Georg Baum wrote: > Pavel Sanda wrote: >> Stephan Witt wrote: >>> > What's the status of python 3 on fedora/debian/suse? >>> On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2. >> Default is not so important, important is 3.x availability, we have >> mostly working selection mechanism thanks to Enrico. > 3.2.1 is available in debian squeeze (the current stable version). Since > debian is usually the most outdated linux distro it should not be a problem > to require python 3 if it is avialable on OS X as well. If we stay with > python 2 I'd say that 2.6 is a safe minimum requirement. This could be > raised to 2.7 as soon as RHEL 7 and debian wheezy are released. > BTW I don't see any maintenance burden if we stay with version 2 for another > year or so, as long as we don't support both versions at the same time. I propose to keep supporting 2.x until: * the minimum requirement is 2.7 (i.e. 2.7 is available in Debian/stable), AND * the majority of Python installations defaults to Python 3. I suppose, there is no need to raise the minimum requirement to 2.7 unless we start supporting 3.x. Günter
Re: Python detection
Georg Baum wrote: > 3.2.1 is available in debian squeeze (the current stable version). Wrong, it is 3.1.3, but does not matter. Georg
Re: Python detection
Pavel Sanda wrote: > Stephan Witt wrote: >> > What's the status of python 3 on fedora/debian/suse? >> >> On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2. > > Default is not so important, important is 3.x availability, we have > mostly working selection mechanism thanks to Enrico. 3.2.1 is available in debian squeeze (the current stable version). Since debian is usually the most outdated linux distro it should not be a problem to require python 3 if it is avialable on OS X as well. If we stay with python 2 I'd say that 2.6 is a safe minimum requirement. This could be raised to 2.7 as soon as RHEL 7 and debian wheezy are released. BTW I don't see any maintenance burden if we stay with version 2 for another year or so, as long as we don't support both versions at the same time. Georg
Re: Python detection
Stephan Witt wrote: > > What's the status of python 3 on fedora/debian/suse? > > On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2. Default is not so important, important is 3.x availability, we have mostly working selection mechanism thanks to Enrico. Pavel
Re: Python detection
Op 13-04-13 03:09, Pavel Sanda schreef: José Matos wrote: So these are the facts. The question then is how do we want to proceed? I thought we want to be >3.0 compatible and ditch 2.x series completely(?). Otherwise it looks like just maintenace burden without profit. What's the status of python 3 on fedora/debian/suse? Pavel on openSUSE 12.3 python 2 (2.7.3) is still default, but version 3 (3.3.0) is available. Unknown when default will change. Cor
Re: Python detection
Am 13.04.2013 um 03:09 schrieb Pavel Sanda : > José Matos wrote: >> So these are the facts. The question then is how do we want to proceed? > > I thought we want to be >3.0 compatible and ditch 2.x series completely(?). > Otherwise it looks like just maintenace burden without profit. > > What's the status of python 3 on fedora/debian/suse? On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2. Stephan stephan$ python -V Python 2.7.2 stephan$ which python /usr/bin/python stephan$
Re: Re: Re: Python detection
José Matos wrote: > So these are the facts. The question then is how do we want to proceed? I thought we want to be >3.0 compatible and ditch 2.x series completely(?). Otherwise it looks like just maintenace burden without profit. What's the status of python 3 on fedora/debian/suse? Pavel
Re: Re: Re: Python detection
On Friday 12 April 2013 12:35:57 Pavel Sanda wrote: > You are the pythonist here > P :-) The issue is what is the minimum version of python that we want to support. If we decide to stay with python 2 as the default version the question then becomes what is the minimum version we want to support. According to http://en.wikipedia.org/wiki/History_of_Python the minimum version of python that we are using now has been released more than 8 years ago. * Python 2.0 - October 16, 2000 * Python 2.1 - April 17, 2001 * Python 2.2 - December 21, 2001 * Python 2.3 - July 29, 2003 * Python 2.4 - November 30, 2004 * Python 2.5 - September 19, 2006 * Python 2.6 - October 1, 2008 * Python 2.7 - July 3, 2010 The main differences between 2.6 and 2.7 is that 2.7 simplifies more the transition process to python 3. The political decision that we need to make is what is the minimum standard we want to set for the python version. For example python 2.7 is only available for wheezy that will be debian 7.0 as well for RHEL 7 that we will be out soon. Both the most up to date current stable versions of these two distributions, that we have used as reference in the past, only carry currently python 2.6. I would expect that they will only switch to python3 by default in 5 years or so (a forecast done with my usual optimism). So these are the facts. The question then is how do we want to proceed? -- José Abílio
Re: Re: Python detection
José Matos wrote: > Are we there at that point? You are the pythonist here :) P
Re: Re: Python detection
On Thursday 11 April 2013 10:59:47 Pavel Sanda wrote: > I think that long term solution was rather to switch to Python 3. > But all such talk is cheap, we need patches > Pavel The first step is to raise the supported python to version 2.7 and then the transition will be easy. That was the whole point of version 2.7 (after version 2.6) was to ease the transition to python 3. That is realistic and an easy task. Are we there at that point? Should that be one of the goals of lyx-2.2-devel? That is what we can decide now. -- José Abílio
Re: Python detection
Guenter Milde wrote: > As a long-term project, I suggest making the Python scripts run with both, > Python 2.x and 3.x (with x some decent choice of not-too-old versions). I think that long term solution was rather to switch to Python 3. But all such talk is cheap, we need patches :) Pavel
Re: Python detection
On 2013-04-11, Pavel Sanda wrote: > Enrico Forestieri wrote: >> On Sat, Apr 06, 2013 at 10:10:48AM -0700, Pavel Sanda wrote: As a long-term project, I suggest making the Python scripts run with both, Python 2.x and 3.x (with x some decent choice of not-too-old versions). For simple modules, this could be achieved by some compatibility definitions and avoiding incompatible syntax. For larger modules/packages, I suggest providing: * two versions of the module/package, where the Py3x version is generated from the Py2x version with the 2to3 script that comes with distutils. * a front end script that detects the Python version and imports the corresponding module. I have some experience in this field from Docutils development, so I may be able to help implementing. Günter
Re: Python detection
Enrico Forestieri wrote: > On Sat, Apr 06, 2013 at 10:10:48AM -0700, Pavel Sanda wrote: > > > Enrico Forestieri wrote: > > > 2) Every time Systemcall::startscript() is called with a command starting > > >exactly as "python -tt", the "python" string is replaced with the name > > >of the "good" python, e.g., "python -tt" -> "python2.6.8 -tt". > > > > Yep, but there are parts of code like preview machinery which run > > ForkedCall::startScript() and then no python substitution is called. > > Intended or bug? > > Not intended. If this is the case, ForkedCall::startScript() should > mimic what Systemcall::startscript() does. Added to bugzilla, #8631. Pavel
Re: Python detection
On Sat, Apr 06, 2013 at 10:10:48AM -0700, Pavel Sanda wrote: > Enrico Forestieri wrote: > > 2) Every time Systemcall::startscript() is called with a command starting > >exactly as "python -tt", the "python" string is replaced with the name > >of the "good" python, e.g., "python -tt" -> "python2.6.8 -tt". > > Yep, but there are parts of code like preview machinery which run > ForkedCall::startScript() and then no python substitution is called. > Intended or bug? Not intended. If this is the case, ForkedCall::startScript() should mimic what Systemcall::startscript() does. -- Enrico
Re: Python detection
Enrico Forestieri wrote: > 2) Every time Systemcall::startscript() is called with a command starting >exactly as "python -tt", the "python" string is replaced with the name >of the "good" python, e.g., "python -tt" -> "python2.6.8 -tt". Yep, but there are parts of code like preview machinery which run ForkedCall::startScript() and then no python substitution is called. Intended or bug? Pavel
Re: Python detection
On Fri, Apr 05, 2013 at 09:44:49PM -0700, Pavel Sanda wrote: > Enrico, > > what is the status of the python 2 detection you committed some time ago? > Is it just supposed to be fallback in order to avoid worst things or > is lyx supposed to work on systems with both 2.6 & 3.x pythons? It is supposed to automatically use any python version 2. If I remember correctly, it should work like this: 1) At startup, all commands in $PATH whose name starts with "python" are checked and the first of them that declares to be version 2.x is taken to be a "good" python version. 2) Every time Systemcall::startscript() is called with a command starting exactly as "python -tt", the "python" string is replaced with the name of the "good" python, e.g., "python -tt" -> "python2.6.8 -tt". This means that if you call python using an absolute path or with a name like "python3.0", no substitution takes place and that version of python (whatever it is) is used instead. > Is see errors like > > Found Python 2.6.8 > > File "/lyx/devel/lib/scripts/lyxpreview2bitmap.py", line 293 > except getopt.GetoptError, err: > ^ > SyntaxError: invalid syntax > > when default python links to 3.x. This means that either you do not invoke python exactly as "python -tt" or there is a flaw in the automatic substitution code. -- Enrico
Python detection
Enrico, what is the status of the python 2 detection you committed some time ago? Is it just supposed to be fallback in order to avoid worst things or is lyx supposed to work on systems with both 2.6 & 3.x pythons? Is see errors like Found Python 2.6.8 File "/lyx/devel/lib/scripts/lyxpreview2bitmap.py", line 293 except getopt.GetoptError, err: ^ SyntaxError: invalid syntax when default python links to 3.x. Pavel
