flit
flit copied to clipboard
flit install --symlink and --pth-file should check for the requires-python metadata
User has code which has a dependency on some Python version, e.g.:
# issue309.py
"""A module demonstrating a hard dependency on python 3.7+"""
__version__ = "0.1"
def __getattr__(self, attr):
if attr == "potato":
return "spud"
raise AttributeError
And then in the toml we specify the metadata, to guard against accidental installation into unsupported Python env:
[build-system]
requires = ["flit_core >=2,<3"]
build-backend = "flit_core.buildapi"
[tool.flit.metadata]
module = "issue309"
author = "Wim Glenn"
author-email = "[email protected]"
requires-python = ">=3.7"
It works OK for bare flit install, since that builds a wheel and installs the wheel:
$ flit install
...
ERROR: Package 'issue309' requires a different Python: 3.6.7 not in '>=3.7'
However this check came from within pip, and the other branch for --symlink or --pth-file doesn't get it. Installation succeeds but app behaves strangely at runtime.
I started to code this check into flit.install, but it seems that doing it correctly is pretty involved, you kind of have to reinvent packaging's SpecifierSet otherwise that project wants to pulls in pyparsing and ... ugh, it seems a bit too heavy for flit.
Any advice on how to proceed here? Does flit already have some PEP440-style parsing anywhere that I can re-use?
Thanks, this is a good idea.
Currently, the only parsing it does of that field is to validate that it matches the expected format:
https://github.com/takluyver/flit/blob/7cd39b0747aa0689e02fd87359d08ad0232d69d1/flit/validate.py#L147-L151
#261 should also be solved by parsing and checking the Python version specifier. I wonder if this is easier to do for Python version numbers than for arbitrary version numbers, because we can assume a fair bit of regularity.
@takluyver got bitten by this again the other day, has anything changed in flit or flit-core since jan 2020 where parsing requires-python for development installs would be easier now?