python-template: Linting build not working
The Build workflow fails in this line:
The error is the following:
Run prospector
prospector
shell: /usr/bin/bash -e {0}
env:
pythonLocation: /opt/hostedtoolcache/Python/3.9.16/x64
LD_LIBRARY_PATH: /opt/hostedtoolcache/Python/3.9.16/x64/lib
Cannot run tool pyroma as support was not installed.
Please install by running 'pip install prospector[with_pyroma]'
Error: Process completed with exit code [2](https://github.com/EDG-Acoustics/edg-acoustics/actions/runs/3882655432/jobs/6623058120#step:7:2).
I have forced installing prospector with pyroma, adding a line python3 -m pip install prospector[with_pyroma], forced the reinstall with --ignore-installed, and confirmed that it is installing it (seems so):
INFO: pip is looking at multiple versions of pyroma to determine which version is compatible with other requirements. This could take a while.
Collecting pyroma>=2.4
Downloading pyroma-4.0-py2.py3-none-any.whl (28 kB)
I still get the error. Did someone face the same problem or does anyone know what could be the issue?
Thanks!
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 27 (27 by maintainers)
I’m not super-strict with this, as it’s all broken anyway, but I can see both sides of the equation. Numpy for example releases fairly frequently and doesn’t guarantee a lot of future stability, so setting an upper bound that is guaranteed to work means you need to re-test and re-release often. Wait too long and your software won’t install anymore, even though it’ll probably still work. That’s been an issue with MUSCLE3.
For YAtiML, I heavily depend on ruamel.yaml and that is a mess, active development, no defined API, no compatibility guarantees, and broken releases fairly regularly. I have a script that tests against all releases of the last couple of years, and then put in a version constraint with lower and upper bounds and excludes for known-broken versions. I’ve had issues with people installing some other software that required a recent version that I hadn’t tested against and getting version conflicts, but I don’t dare to release the constraints either. The real solution is to finally invent NAML, but well, when I find a round tuit.
Otherwise, I’m also often sloppy and don’t set a version constraint at all. If the dependency is some random Python package that some dude (f/m) made years ago and hasn’t touched since, then it’ll continue to work anyway…
I scanned the article. A strong argument is interaction with other libraries, which you do not control. You need library A with R.A requirements, but then you need B with R.B requirements, with strict (conservative) versions the compatible intersection can (and will) be zero.
If you have a couple of hours, take a look at this 😉 https://iscinumpy.dev/post/bound-version-constraints/
Tl;dr: https://iscinumpy.dev/post/bound-version-constraints/#tldr
We also discussed it (incompletely) in Teams at some point, you can probably find it if you search for the link.
@apalha that’s the problem semantic versioning is supposed to solve. Major version number increases (can be / are allowed to be) incompatible ; minor version number increases (should be) backwards compatible. A point release should be only bug fixes etc. Then it’s up to the user if they want latest or not. For security reasons, it makes sense to always use the latest release, but for some other usecase stability (and no changes) is more important.
I think I would be against replacing
prospector. It’s true that it sometimes bugs a bit, but that’s probably because it combines a lot of tools. If we were to combine all those tools ourselves in our custom workflow we would carry the same maintenance burden. I personally think they are all useful, although surely this differs from project to project.Interesting. It seems that the Prospector issue linked from the DIANNA issue only fixes the problem that pyroma doesn’t install automatically, but user volans also mentions that it doesn’t run correctly, and that’s what we’re seeing here as well.
So I did some more investigating and found the problem, only to discover that it was found by someone else four days ago, and that a fix had been in the repo for an hour already!
https://github.com/PyCQA/prospector/pull/574
So it should work again from 1.8.4 onwards. Meanwhile, the solution is to limit the prospector version to <1.8.0; I cannot reproduce this on 1.7.7 at least.