Deprecate the tests made with Python 2.7 ? about jsbsim HOT 15 CLOSED

Ah, ok I see you don't try do a directory filter of Bash's directory enumeration, you go through each, and invoke a simple python script to check which version of python is executed and filter based on the returned python version.

Correct.

I guess the issue can be closed now.

from jsbsim.

I've been on Python 3.x only for a couple of years but I'm pretty sure there are a number of people who still use 2.x because of inertia or having some libraries that are only available for 2.x. Difficult to know how many JSBSim python 2.x users there are.

But is it not the case with the recent commits that both Python 2.x and 3.x are supported without any major issues/ifdefs etc.?

from jsbsim.

Is there a good reason why we should not deprecate a Python version which will not be supported in the future?

Is cython 3.x is broken on my platform one such reason ? :-)

from jsbsim.

More seriously, as @seanmcleod said, there are still quite a number of Linux distributions which are still based on Python 2.7.x (including Fedora). I guess that once these distributions will have finalized their migration we will be able to drop the support of Python 2.7.x

Meanwhile it doesn't harm much since JSBSim Python code is now compatible with 2.7 and 3.x

from jsbsim.

Agreed.

I've noticed that the Travis build for Python 2.7 results as a failed task.

from jsbsim.

I've noticed that the Travis build for Python 2.7 results as a failed task.

Indeed TestInputSocket fails from time to time likely due to a race condition. Strangely enough it seems to occur only with Python 2.7. I'll open a separate issue for that.

from jsbsim.

I'll open a separate issue for that.

Done, issue #31 has been created to log the problem.

from jsbsim.

For the record, once we will be able to drop Python 2.7, we will be able to declare the project as a C++ project to Travis CI instead of a Python project which benefits will be the following:

• The project can be checked against 2 compilers (gcc and clang) instead of only one (gcc)
• Travis CI should be able to build JSBSim on OS X

from jsbsim.

Since Python 2.7 has reached its official end of life since Jan 01, 2020, I suggest that JSBSim drops its support as well and this issue should be closed.

from jsbsim.

@bcoconni, @agodemar looking at .github\workflows\cpp-python-build.yml I don't see any references to Python 2, only references to Python 3 (for Windows multiple 3.x versions). I haven't double-checked appveyor and travis, assuming they're the same we can then close this issue?

from jsbsim.

Actually we are still producing wheel packages for Python 2.7 since the Docker image we are using to produce wheels compatible with "Many Linux" distributions is still including a copy of Python 2.7 (and Python 3.4 which is no longer supported by the Python Foundation either).

Of course, the script build-wheels.sh could be modified to exclude the unsupported versions but I am not very familiar with bash syntax so it will need some investigation to find out how to proceed.

Travis is also producing Ubuntu packages for Python 2.7 but this script should be much easier to fix.

The bottom line is yes we have dropped support of Python 2.7 as a goal but it remains to materialize in the building and deployment scripts.

from jsbsim.

I have just committed 9416ea9 which removed the build & deployment of Ubuntu packages for Python 2.7

from jsbsim.

I'm assuming the following snippet from build-wheels.sh is enumerating /opt/python/* and finding multiple python versions installed, e.g. 27, 36 etc. and then building a wheel for each python version?

# Compile wheels
for PYBIN in /opt/python/*/bin; do

I don't have a Linux installation to double-check what /opt/python looks like.

Guessing, with no real Bash expertise that something like /opt/python/3*/bin might work?

from jsbsim.

I'm assuming the following snippet from build-wheels.sh is enumerating /opt/python/* and finding multiple python versions installed, e.g. 27, 36 etc. and then building a wheel for each python version?

Correct.

Guessing, with no real Bash expertise that something like /opt/python/3*/bin might work?

It might work indeed. Unfortunately I have used a far more convoluted syntax (commit c4ea819) to drop every Python version earlier than 3.5 since they are now all deprecated as can be seen in the table of version of Python from Wikipedia.

from jsbsim.

Ah, ok I see you don't try do a directory filter of Bash's directory enumeration, you go through each, and invoke a simple python script to check which version of python is executed and filter based on the returned python version.

from jsbsim.