Feature Request: Allow reading dependencies (and dev-dependencies) from `requirements.txt` file

While it isn’t a huge maintanance burden it would be nice if we could share our requirements files between tox, CI & packaging.

I guess this should either be done by adding tox/PIP-style syntax to for requires:

requires = -r requirements.txt

or adding a separate requires-file option. I’d prefer the first option because it is similar to how tox handles this stuff (it was the first thing I tried anyways) and because it makes it more obvious that the external file belongs to the same requirement list as the other stuff possibly listed.

[takluyver]

I believe tox now supports PEP 517, so it should be able to get requirements from a flit package.

The requirements you specify with flit are abstract requirements (see Donald’s blog post about this). requirements.txt is typically used to specify concrete, pinned dependencies. So reading that doesn’t make sense.

You could write a tool which reads dependencies specified for Flit and creates a list of pinned versions for them. They’re configured in Flit’s section of the pyproject.toml file, so you’re at the mercy of Flit changing the format for dependencies, but I don’t see that happening in the near future.

Or look at other tools like poetry and pipenv which handle translating abstract dependencies into concrete ones.

[romanchyla]

leaving comment here just in case it helps someone; I’m using the following which works

credit: https://stackoverflow.com/questions/32688688/how-to-write-setup-py-to-include-a-git-repository-as-a-dependency

[project]
...
dependencies = [
    'rutils @ git+https://github.com/romanchyla/rutils@#egg=rutils',
]

[build-system]
requires = ["setuptools >= 58.6.0", "wheel", "flit_core >=3.2,<4", "ppsetuptools==2.0.2"]
#build-backend = "setuptools.build_meta"
build-backend = "flit_core.buildapi"

I find the distinction between abstract/concrete dependencies to be way too abstract to be pragmatic and/or useful; when we are developing libraries we also tend to develop applications that use those libraries; it’s a messy world, so our tools need to be simple but not simpler than necessary…