Correct CI

[szszszsz]

At the moment CI fails with:

venv/bin/flit install --symlink
make: venv/bin/flit: Command not found
Makefile:60: recipe for target 'update-venv' failed
make: *** [update-venv] Error 127
The command "make init" failed and exited with 2 during .

• To correct
• Build MSI package for Windows MSI Installer + Instructions for Windows #26

[szszszsz]

Mostly fixed with f46bd38

[szszszsz]

I got it broken again unfortunately, due to trying to call the nitropy after flit installation.
It works on Python 3.8 though: https://travis-ci.org/github/Nitrokey/nitro-python/jobs/700871763

[szszszsz]

Build fails due to problem with extending some Bash features apparently, see:

• https://app.circleci.com/pipelines/github/Nitrokey/pynitrokey/43/workflows/aee09360-d542-478e-ae78-545e0b126687/jobs/183

python -m pip install pynitrokey== 2>&1 | grep -oE ", ([^,]+), ([^,]+)\)$" | cut -d "," -f 2 | xargs > LAST_VERSION
python -m pip install pynitrokey==`cat LAST_VERSION | xargs`
Defaulting to user installation because normal site-packages is not writeable
ERROR: Could not find a version that satisfies the requirement pynitrokey==
ERROR: No matching distribution found for pynitrokey==

[szszszsz]

@daringer @robin-nitrokey Could you take a look into this?

[szszszsz]

@daringer @robin-nitrokey @LennardBoediger
Just a friendly reminder. Having a broken CI kind of misses the point :-)

[robin-nitrokey]

It is hard for me to fix this properly because I’m not sure what it is trying to achieve. Apparently, it is trying to install the latest version, but couldn’t we use ${VERSION} instead of grepping the pip output? I can prepare a PR that does that but I’m not sure if that’s the intention.

[robin-nitrokey]

Also, as these tests only check the installation via pip/PyPi and not the actual code in the repository, wouldn’t it make sense to use scheduled builds instead of running them for every push?

[szszszsz]

@daringer Could you review the mentioned #75 and see if that is according to your design? LGTM.
@robin-nitrokey Yes, scheduled builds would be ideal solution for this, as what we wanted here is to check, when the package will stop installing due to the changed external dependencies (especially important on not locked versions).

[szszszsz]

This one got closed without explanation, but I believe the reason was we have moved to Gitlab CI, thus this one got outdated. Still the hook was connected to Circle CI until now. Removing it.