PYTHON versions on appveyor?

Development
1

Hi guys,

esp @ntamas we mentioned earlier that we should stop having a gazillion CI runs on AppVeyor since different Python versions are unrelated to the C interface anyway. Is that still our intention?

Thx
Fabio

2

@vtraag explained in one of the other threads how Python is related to the C core but I can’t remember where (I was just skimming through it quickly as I was short on time, and I can’t find it now). @vtraag, can you explain it here once again pls? I believe that even if we decide to keep the Python parts in the CI, we should strive to cut down on the number of versions we test things with – maybe the oldest Python 3.x version that has not reached its EOL yet would suffice? (At the time of writing it’s Python 3.5).

3

Well, yes, indeed, the reason to keep the different python versions is to make sure that compilation of the C code is compatible with the quirks of different MSVC compilers. Perhaps most notably (or at least visibly) is the C89 requirement for variable initialisation and the comment style (/* */ only). There are perhaps a number of other things, I don’t know immediately.

I think it would be good to only compile for the 3.x versions that have not reached EOL yet (>=3.5 at the moment). This means we only need to compile using VC 14, available from Visual Studio 2015 and upwards. For some reason Python 3.4 does not seem to be actually used for compilation is seems (i.e. VC 10), so the only difference would then be to get rid of Python 2.7 (i.e. VC 9), which makes sense to me.

Note that we also want to compile for mingw/msys separately, as we also want to support that platform on Windows (and I believe that is used for R compilation).

4

One thing that might not be immediately clear from this is that the version of the MSVC compiler needed to compile a Python extension for a certain version of Python depends on the Python version. Here is the full table.

If we decide to phase out Python 2.x (which has reached its EOL in January) and Python <= 3.4, then we only need to test with VC 14 as @vtraag has indicated, so we can cut down the list of MSVC versions that we test in CI to VC 14, which would save us quite a bit of time.

Note that if I understand correctly, using PYTHON in the CI env description is actually a misnomer; we are not really testing things for Python, we just use the Python version number as a proxy to the corresponding MSVC version, and what we are actually interested in is whether igraph compiles with that particular MSVC version.

So, in the end, we would need three CI runs then:

  • MSVC 14
  • MSYS
  • MinGW

Is that correct?

5

Almost. The build script for preparing the MSVC compilation (i.e. make msvc) has Python dependencies. Also for that reason, I think it is useful to test it. However, with the upcoming CMake based build, make msvc will become redundant, and will then no longer need to be checked for that reason. Nonetheless, I think the MSVC compilation is the main reason.

We only need to check VC14 indeed. And let’s make it clear in AppVeyor.yml that is is simply about compiling with VC14.

Regarding MSYS and MinGW, they refer to the same platform. Or well, the MinGW 64 compiler is available only on the msys2 platform, I believe. Not entirely sure about all the differences, but the point is: it is actually only one CI that should be run.

Alternatively, we could also do a CI for cygwin, which does use a different system than msys2. So, it might be useful to test that additionally.

6

msys2 comes with multiple compilers. The default one is like cygwin, produces executables dependent on msys2.dll, and I think it uses Unix line endings. The mingw-w64 ones produces standalone windows executables suitable for redistribution.

1 Like
7

Let me try and summarize, then you guys tell me if that’s correct:

  1. we can dump python2.7
  2. we can consolidate python 3.5-3.8+, if not immediately, for sure after CMake
  3. we need to write a comment in the appveyor config file about MSVC14 being the one tested
  4. we need three runs on AppVeyor: MSVC14, MSYS2 + CYGWIN, MSYS2 + MinGW64 (for standalone redist)

That all?

8

Yes

Yes

I would propose to simply rewrite the AppVeyor file so that it is simply clear that we are compiling with VC 14, instead of using a Python version and commenting on it.

Yes

9

To be accurate, that is not cygwin, it is like cygwin.

Also, I do not currently think that there is a reason to test with that compiler, but then I am not sure about it. That’s a sort of Unix emulation on Windows, it seems like kind of a niche application. Perhaps testing on real Unix (Mac/Linux) and on native Windows (MinGW-w64 and MSVC) is sufficient?

10

I’m not sure either whether cygwin(-like) is really necessary. Some people on Windows might use it, I’m not sure. I don’t have anything against not testing that.

11

Great thanks! New summary

  • we can dump python2.7
  • we can consolidate python 3.5-3.8+, if not immediately, for sure after CMake
  • we need to rewrite the appveyor config file to specify MSVC14 instead of the PYTHON variable proxy
  • we need two runs on AppVeyor: MSVC14 and MSYS2 + MinGW64 (the latter for standalone redist)

@vtraag @tamas would you like me to take a stab at this pruning exercise? Or you prefer to do it yourselves since you have done it last time?

12

Started working on it in the chore/appveyor-msvc-cleanup branch.

1 Like
13

Branch pushed, all tests seem to pass. Guess we can close this then?