Inconsistent project dependencies

[croxxx]

Observation

This is a small detail I found after digging around the code to analyze #130 and #131. It seems this is related to two recent merge requests #110 and #122.
Without being too familiar with Python tooling, I noticed that the dependency definitions differ between pyproject.toml, requirements.txt and requirements-dev.txt.

File	Version
pyproject.toml	anki = "2.1.49"
requirements.txt	anki==2.1.40; python_version >= "3.8"
requirements-dev.txt	anki==2.1.49; python_version >= "3.8"

My assumption would be for those to be identical, yet the requirement explicitly stated in #110 (comment) is violated by requirements.txt.

Suggestion

Assuming dependencies are to be exclusively managed by the tool reading pyproject.toml, I suggest the following:

• Remove requirements.txt and requirements-dev.txt as they are auto-generated on build.
• Add requirements.txt and requirements-dev.txt to .gitignore to prevent checking in inconsistent versions in the future.
• Clearly update build documentation stating how dependencies are managed in this project.

[VikashKothary]

Hi @croxxx,

Thanks for bringing this to my attention. The Pyproject.toml is the correct version and I will update the other files now to fix the inconsistency.

I understand your suggestion however poetry is still a relatively new tool in the scope of Python. While I love it, there is a large number of users who use other tools like virtualenv and conda. The generated requirements.txt files are kept there to allow those users to use their preferred package manager.

It's also important to note that generating the requirements.txt requires poetry which means that they would have to download it even if they don't want to use it.

There is a PR open which hopes to prevent this issue from occuring in the future by using GitHub Actions to automatically update the reqirements.txt files when the pyproject.toml is updated. See: #126.

Is this an acceptable solution?

[croxxx]

Ah, that is a reasonable approach.

In addition to the changes proposed in the PR I can imagine some sort of sanity check downstream.
For example, the Docker build could always recreate requirements files based on the poetry base. That way even bad dependencies cannot "poison" the build and the specific versions are locked anyways. Downside of this approach would be masking errors, of course.

As the immediate issue has been resolved for now and there is changes proposed improving the general behavior, feel free to close this.

[ohdearaugustin]

Should be fixed now with #126

[VikashKothary]

The PR has been merged. So hopefully we should not have this issue in the future.

Thank you @croxxx for raising this issue and @ohdearaugustin for your help in resolving it. It is much appreciated.