dkpro / dkpro-cassis

UIMA CAS processing library written in Python
https://pypi.org/project/dkpro-cassis/
Apache License 2.0
84 stars 22 forks source link

#316 - Switch to using plain pyproject.toml #317

Open reckart opened 2 months ago

reckart commented 2 months ago

What's in the PR

How to test manually

Automatic testing

Documentation

codecov[bot] commented 2 months ago

Codecov Report

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

Project coverage is 91.43%. Comparing base (a76b4e1) to head (473e3d6).

Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #317 +/- ## ========================================== - Coverage 95.47% 91.43% -4.04% ========================================== Files 5 5 Lines 2009 2009 Branches 0 520 +520 ========================================== - Hits 1918 1837 -81 Misses 91 91 - Partials 0 81 +81 ```

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

reckart commented 2 months ago

@DavidHuebner does this look more reasonable to you?

DavidHuebner commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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.