Error following modification of check scripts about kicad-library-utils HOT 14 CLOSED

Yes travis is stuck at python 2 until you close and reopen the pull request. I know this is annoying especially as we now kind of rely on python 3 for the tests. (I did not know about this travis restriction when i merged the changes. Otherwise i would have updated to python 3 a bit before merging the changes that require python 3.)

Edit to make it clear: only pull requests that existed before my changes are stuck at python 2. I would even assume that only commits that where made before that are stuck. Meaning users would never see problems as they can not restart travis in any way other than either adding a new commit or opening and closing the pull request both of which get travis over to python 3. This of course means that we maintainers for now also need to restart travis by closing and reopening the pull request instead of going via the travis interface.

And no python 2 is dead. I am not prepared to invest any time in getting any script compatible with both. (We are at least 3 years late with this decision. I do not quite understand why we even bothered to have them python 2 compatible in the past. This just added additional effort for no real tangible gain)

from kicad-library-utils.

Odd, Travis is still using Python 2...

from kicad-library-utils.

Since build #5023 Travis has been using Python 3 with no complaints.

from kicad-library-utils.

@myfreescalewebpage this build/PR is quite old, but only ran recently, evidently in the period between #274 being merged and the update to Python 3. Did you re-run this build to test it out?

from kicad-library-utils.

@fauxpark it was the last time run 2 days ago. The PR is now merged and we are now more able to restart the run (it fails because PR is merged).

from kicad-library-utils.

Seems not to be present on the last run in the pull request I'm currently reviewing. Closing the issue at the moment.

from kicad-library-utils.

I think this is actually expected behaviour if Travis pulls the .travis.yml from the same point in the Git history as the PR. @poeschlr advised not to bother with support for Python 2 in this rule, or the check scripts in general.

So, it doesn't fail because my PR was merged, it fails because it's trying to use Python 2 to check this rule.

from kicad-library-utils.

@fauxpark seen again today 2019-30-03, reopening the issue.
How have you made your previous modifications ? Python 3 ? You should be compatible with Python 2.....

from kicad-library-utils.

@poeschlr I'm not sure but it seems that:

• travis is triggered with python 3 when a commit is pushed
• travis is triggered with python 2 when we relaunch the tests manually with the "Restart build" button....

from kicad-library-utils.

That is interesting. Evidently Travis pulls the .travis.yml from current master for a new build (regardless of where the PR was branched off of), but when rerunning an existing build the Python version is already stored somewhere in the metadata for the build so it simply uses that one.

@myfreescalewebpage this thread appears to offer a solution: https://travis-ci.community/t/can-restart-build-to-use-latest-travis-yaml-configuration/1384

from kicad-library-utils.

@fauxpark the main issue is that it is not "my" pull request, this is the pull requests of people contributing to the library that we are reviewing... Keeping compatibility with python2 should be very great, isn't it possible ?

from kicad-library-utils.

It is possible, in fact that's what my PR did originally, however Rene seemed to be saying not to bother: #274 (comment)

So I defer to him as to what to do next.

from kicad-library-utils.

@poeschlr is it tested that closing/opening the PR will restart travis with the new configuration, i.e. running python3 ?

from kicad-library-utils.

Just confirmed, the issue can be solved by closing/opening the pull request. Closing this issue.

from kicad-library-utils.