|
From: Bill S. <g4...@cl...> - 2015-04-28 23:37:04
|
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 :(
>
> 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.
>
>
> 73's
> Greg, KI7MT
>
>
> On 04/28/2015 05:07 PM, Bill Somerville wrote:
>> On 28/04/2015 23:57, KI7MT wrote:
>>> Hi Bill,
>> Hi Greg,
>>> Yes, AsciiDoc works with Python2.5 through the latest Python2 which is
>>> Python2.7.9 I believe. There won't be a Python2.8 from what I understand.
>>>
>>> However, AsciiDoc *will not* work with Python3.x., which is what WSPR
>>> and WSJT use.
>> Ah OK.
>>
>> So how do you deal with that on Linux? Do you have to do an alternate
>> Python package switch every time you move between docs and WSPR/WSJT?
>>>
>>> 73's
>>> Greg, KI7MT
>> 73
>> Bill
>> G4WJS.
>>>
>>> On 04/28/2015 03:28 PM, Bill Somerville wrote:
>>>> On 28/04/2015 22:12, Bill Somerville wrote:
>>>>
>>>> <snip>
>>>>
>>>>> For Windows, adding Python27 is a sensitive situation with regards to
>>>>> WSPR and WSJT builds. I will need to do some testing. Will take fare bit
>>>>> of time to sort that all out.
>>>>> Looking at the asciidoc prequisites it says Python 2.4 and up is OK so
>>>>> it may not be an issue. I haven't put any Python checks in the WSJT-X
>>>>> CMake script, it just finds asciidoc and takes the view that if you have
>>>>> installed asciidoc then you really ought to have a working Python around.
>>>> I've just tried asciidoc on Windows with Python 2.5 and it works fine.
>>>>
>>>> <snip>
>>>>
>>>> 73
>>>> Bill
>>>> G4WJS.
|