Re: [wsjt-devel] WSJT-X: User Guide built with CMake - was: Re: WSJT-X: User Guide updates for v1.5.0

[KI7MT <ki...@gm...>]

Hi Bill,


On 04/28/2015 05:36 PM, Bill Somerville wrote:
> On 29/04/2015 00:27, KI7MT wrote:
>> Hi Bill,
> Hi Greg,
>>
>> Linux is designed to run multiple versions of Python simultaneously.
>> e.g. Py2 and Py3. Or at least, the Debian based Distros are. That's not
>> the case for some others. I can't speak to how Arch, Slack, Fedora etc
>> manage multiple Python version installs.
>>
>> If you call python -V on a standard Ubuntu / Debian System, you will
>> most like get 2.7.x back as the version. If calling python3 -V, it
>> should return 3.3.x or 3.4.x or later. Scripts requiring python3, should
>> list it in the shebang stating as such:
>>
>> #!/usr/bin env python3
> That seems dangerous to me, all those scripts are going to die when 
> Python 4 replaces Python 3, sounds like the Millennium Bug all over again :(

I don't think there's anythe worry about Python4 rolling out any time
soon :-), as in, it is years away. I've not even seen a spec for it
anywhere. Using the Shebang is the recommended way on a Multi Python system.

Python Major version changes are not like Compilers or r Qt changes,
they happen "Very Slowly", when moving from Major to Major (2 to 3 or 3
to 4).The transition from 2 to 3 has taken years and it's far from complete.

>>
>> Most of the Debian based distros are still locked to Python2 as it's
>> core Python, but that is changing. Ubuntu and Debian are agressively
>> updating to Python3, but there are 1000's of package deps on Python2, so
>> it's taking a while.
>>
>> Here's another issue. Some distro's do not have Python2 installed as a
>> default package (Arch for example). So, if I were to install python3,
>> and then type python-V .. it would render the python3 version.
>>
>> Needless to say, the transition from Py2 and Py3 has been messy for all
>> OS's, not just Linux.
>>
>> The only way to Isolate Py2 and Py3 in Windows is through a Python
>> Virtualenv which ensures both Python versions are not on the path, which
>> is tricky when using the same Makefile to build both Docs and the App
>> itself, but it can be done.

> I suppose I could invoke asciidoc like:
> 
>     ${PYTHON_EXE} ${ASCIIDOC} ....
> 
> which would bypass the shebang/Windows file associations and allow the 
> location of Python to be set by the CMake finder, that way you could 
> steer the version of Python from CMAKE_PREFIX_PATH.

There is some good news here. Makefiles process things one line at a
time, and in their own shell.

So, if there is a var set for the path to python2, then $(PYTHON)
$ASCIIDOC) x,y,z should only use the Python2 interrupter. Likewise, if
the var is set to Python3, it should work for 3 only.


<snip>

73's
Greg, KI7MT