Stop pinning core dependencies

[0x26res]

Is your feature request related to a problem? Please describe.

When I install falwtydeps on my project, it uninstalls setuptools and import-libmetadata in order to install older version

Installing collected packages: setuptools, pip-requirements-parser, importlib_metadata, fawltydeps
  Attempting uninstall: setuptools
    Found existing installation: setuptools 69.0.2
    Uninstalling setuptools-69.0.2:
      Successfully uninstalled setuptools-69.0.2
  Attempting uninstall: importlib_metadata
    Found existing installation: importlib-metadata 7.0.0
    Uninstalling importlib-metadata-7.0.0:
      Successfully uninstalled importlib-metadata-7.0.0
Successfully installed fawltydeps-0.13.3 importlib_metadata-6.6.0 pip-requirements-parser-32.0.1 setuptools-68.2.2

Describe the solution you'd like

In theory, falwltydeps should work on newer version of its dependencies, so there's no reason to pin these to major versions.

We should replace ^ with >= in pyproject.toml

[tool.poetry.dependencies]
python = ">=3.7.2"
importlib_metadata = ">=6.6.0"
isort = [
    # isort 5.12.0 drops support for Python v3.7:
    {version = "^5.10", python = ">=3.8"},
    {version = ">=5.10,<5.12.0", python = "<3.8"},
]
pip-requirements-parser = ">=32.0.1"
pydantic = ">=1.10.4,<3.0.0"
tomli = {version = "^2.0.1", python = "<3.11"}
typing-extensions = {version = ">=4.4.0", python = "<3.8"}
setuptools = ">=68.0.0"

Describe alternatives you've considered

I could install falwltydeps in a different virtual environment, or use pipx

[jherland]

Thanks for your report! I started looking into this.

I know that we are relying on some not-necessarily-public peculiarities in setuptools and/or importlib-metadata, so we'll need to run some tests before committing to loosening these versions.

[0x26res]

would you recommend having fawltydeps installed in a different venv or with pipx (like poetry does)?

Because then this would not be a problem any more.

[jherland]

Any method should work, and we really do want to support installing FawltyDeps in the same venv as your project (when the versions of dependencies otherwise align).

If you are considering creating a different venv just for FawltyDeps' sake, then I would say that you could just as well use pipx (AFAIK that is ~precisely what pipx actually does, in addition to modifying your $PATH).

Which method should be preferred really depends on what kind of projects you're working with, and how you prefer to work with them: If your project provides a dedicated developer environment and specifies its own dev dependencies, then we hope you will consider including FawltyDeps among these. Otherwise, having FawltyDeps generally available on your machine is certainly not a bad idea, and makes it easy to casually run FawltyDeps on any Python project.

BTW, my local tests of your proposed change is successful, and PR #409 should fix this issue. The first commit in that PR just replicates your suggested changes above, so if you want, I'm happy to update the authorship of that commit to your name/email.