Closed bhaller closed 2 years ago
Why do you have setup-python
set to false? I am thinking that might cause the issue
Why do you have
setup-python
set to false? I am thinking that might cause the issue
Well, I am not sure – somebody else initially set up the GitHub workflow script for me, and I'm still trying to understand all the details of it. It's at https://github.com/MesserLab/SLiM/blob/master/.github/workflows/tests.yml by the way. I think perhaps Python gets set up previously somehow? It worked fine, with install-qt-action@v2
, until it suddenly broke some time between 12 days ago and today.
Upon further head-scratching: there are a couple of "jobs" in the YAML. The "CLI" job needs python, and installs it, and it does not need Qt so it does not run install-qt-action
. That seems to be fine. The "GUI" job needs Qt so it runs install-qt-action
; it doesn't need python for anything, though, so I guess it passes false for setup-python
because it simply doesn't need python. That used to work with @v2
. I guess it seems like with @v3
, install-qt-action
is failing with the above python-related error even though setup-python
is false (and thus I would expect install-qt-action
to simply not try to do anything pythonic at all). So my guess is that perhaps some part of install-qt-action
should be checking for setup-python
being false and skipping some pythonic stuff in that case; or maybe setup-python
being false should simply no longer be supported, if doing pythonic stuff is now always necessary...? But I'm still struggling to understand what's going on, so I could be totally wrong about all this.
It looks like with my latest commit to the workflow YAML, I got the CI working by using @v2
for ubuntu-18.04 and @v3
for the other platforms:
# The jurplel/install-qt-action script @v3 seems to not work on this platform, stick for @v2 for now
# once https://github.com/jurplel/install-qt-action/issues/163 is fixed this can probably be removed
- name: Install Qt v2
if: matrix.qtinstaller_v == 'v2'
uses: jurplel/install-qt-action@v2
with:
version: ${{ matrix.qt }}
setup-python: false
- name: Install Qt v3
if: matrix.qtinstaller_v == 'v3'
uses: jurplel/install-qt-action@v3
with:
version: ${{ matrix.qt }}
setup-python: false
So it does seem like @v3
is just failing on ubuntu-18.04 for some reason, with the settings I'm using, and reverting to @v2
on that platform fixes the problem.
Okay, so the way it works, setup-python
calls the setup-python github action to set up a known working version of python.
The software that actually installs Qt is entirely written in Python and requires a supported version of Python to run.
setup-python
is most commonly used for self-hosted runners, where the setup-python github action doesn't work.
It might not be working now because v3 updated the python library's major version--it might be less accepting of old python versions? I would encourage you to just try setting it to true to see if it works.
OK, I'll try that, hold on.
OK, the new build with that fix has gotten past the Qt install on all platforms with @v3
, I think, so all seems to be well. Thanks very much for your advice, flipping this flag would not have occurred to me for a very long time. :-> Closing.
Glad I could help!
Hi! I'm pretty clueless about Python, GitHub Actions, etc. I've got a project that uses install-qt-action; it has been working nicely for months, using
@v2
(but this issue is for@v3
, read on), and then that recently stopped working on macos-10.15 with this error (log: https://github.com/MesserLab/SLiM/runs/8253692308?check_suite_focus=true):After a bit of head-scratching I realized that
@v3
had been released so I updated mytests.yml
to that. Unfortunately, that now gives a different error, now on ubuntu-18.04 (log: https://github.com/MesserLab/SLiM/runs/8254237001?check_suite_focus=true):I have no idea what any of this means, but it looks like
@v3
is in some way unhappy on ubuntu-18.04. My next stab in the dark will be to conditionally use either@v2
or@v3
depending upon the platform, if I can figure out the syntax for doing that. :-> But this seemed like possibly an issue worth reporting; or more likely, you can at least tell me what I'm doing wrong. Thanks.