#316 - Switch to using plain pyproject.toml

[reckart]

What's in the PR

• Manage dependencies in requirements files
• Use pip-tools to manage dependencies
• Remove poetry

How to test manually

• Build / release

Automatic testing

• [ ] PR includes unit tests

Documentation

• [ ] PR updates documentation

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 91.44%. Comparing base (473e3d6) to head (916a962). Report is 5 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #317   +/-   ##
=======================================
  Coverage   91.43%   91.44%           
=======================================
  Files           5        5           
  Lines        2009     2010    +1     
  Branches      520      446   -74     
=======================================
+ Hits         1837     1838    +1     
  Misses         91       91           
  Partials       81       81           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[reckart]

@DavidHuebner does this look more reasonable to you?

[DavidHuebner]

The project structure looks fine, but I have some doubts if pinning all the versions is really a good idea for dkpro-cassis (sorry if I only make the argument now).

So, generally cassis is installed as part of larger projects as an auxiliary module and not as a standalone library. We should be flexible to deal with the dependency ranges in other libraries. For instance, attrs is used in jupyterlab and we previously had a problem that attrs was too tightly specified in cassis (see #293 ). If we now pin all dependencies, we will run into more dependency conflicts compared to using ranges. Have a look at this discussion as well (https://stackoverflow.com/a/44938662).

Hence, I would actually prefer ranges over specific versions.

[reckart]

I don't mind having ranges for the declaration of compatibility, but I would like to have pinned versions for builds (in particular testing, documentation, etc.). Is that possible?

I.e. when setting up the venv for building, I want to have fixed versions. When another library uses cassis, it should look at the compatibility declarations in the package metadata. My understanding is that the version declarations in pyproject.toml would declare the compatibility while the requirements.txt would be used when setting up the local venv.

[DavidHuebner]

I see. I think you are right. When installing from PyPI, the pyproject.toml should take precedence over requirements.txt and provide flexible versions (just tested it with a plain local pip install .). In contrast, the requirements.txt can be picked up by the local IDE to use fixed versions or the dependencies can explicitly be installed with pip install -r requirements.txt.