Closed ramppdev closed 2 months ago
Great, seems anyway a good idea to find a replacement for iso-639
as it latest release is from 2016.
Did you do any comparison between https://github.com/LBeaudoux/iso639 and https://github.com/jacksonllee/iso639, or is it just random that you picked iso639-lang
?
Currently, the tests fail with:
see https://github.com/audeering/audformat/actions/runs/10865503635/job/30182697617?pr=456.
Locally, I can reproduce the error.
Great, seems anyway a good idea to find a replacement for
iso-639
as it latest release is from 2016.Did you do any comparison between https://github.com/LBeaudoux/iso639 and https://github.com/jacksonllee/iso639, or is it just random that you picked
iso639-lang
?
I have only looked at both of their READMEs and decided to go with https://github.com/LBeaudoux/iso639 as it was updated more recently.
Currently, the tests fail with:
see https://github.com/audeering/audformat/actions/runs/10865503635/job/30182697617?pr=456.
Locally, I can reproduce the error.
Interesting, i am unable to reproduce this on Windows. Pretty sure this means that the wrong library is used.
I tested locally under Linux.
Pretty sure this means that the wrong library is used.
When I start from an empty virtual environment, I don't get the error.
Locally, I could reproduce the error as I first installed iso639-lang
, and then removed iso-639
, so it seems not a good idea if packages use the exact same name for the module.
I guess the problem in the Ci jobs might be that the virtual environment is cached.
I tested locally under Linux.
Pretty sure this means that the wrong library is used.
When I start from an empty virtual environment, I don't get the error.
Locally, I could reproduce the error as I first installed
iso639-lang
, and then removediso-639
, so it seems not a good idea if packages use the exact same name for the module. I guess the problem in the Ci jobs might be that the virtual environment is cached.
Exactly, also just verified that this is what happens. However the issue is that all packages use iso639
.
When running pip install -r requirements.txt
in the CI pipeline it installs:
The problem is that then it runs pip install -r tests/requirements.txt
which installs
For whatever reason it seems not satisfied with the dev version of audformat
when installing tests/requirements.txt
, but installs audformat
1.3.0, which has iso-639
as a dependency.
It seems that when installing the dev version of audformat
the version is wrong:
It should instead be something like 1.3.1.dev1+g7b802c6
. I guess the version of the cloned repository is to shallow and does not contain enough information to define the correct version. I will try to fix this in another pull request.
I fixed the CI job in https://github.com/audeering/audformat/pull/457 and merged it into main
, could you rebase your branch.
Done.
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 100.0%. Comparing base (
20ecec3
) to head (1fdcded
). Report is 1 commits behind head on main.
All looks fine now, thanks again for your contribution. I will merge now and later make a new audformat
release, so you can benefit from the change.
There seems to be an issue with the
iso-639
package in combination with Poetry (very similar to https://github.com/python-poetry/poetry/issues/6996). Poetry is unable to determine the version of the package (see below), thereforeaudformat
as well as any packages that depend on it (likeopensmile
) cannot be used in poetry projects.To reproduce, run
poetry lock
for the followingpyproject.toml
:The workaround for local projects is to directly fetch the package from git:
However, this is not a viable solution for publishing on PyPI, i.e. no package can be published using poetry that depends on
audformat
.This PR replaces
iso-639
withiso639-lang
under the hood to solve the dependency resolution. All tests are passing and runningpoetry lock
with the updated dependency works like a charm.