Closed koubaa closed 11 months ago
You're right that the [scripts]
table in pyproject.toml
is equivalent to what setuptools calls console_scripts
. This is part of the relevant standard (PEP 621).
There's no plan to expose the scripts-as-files mechanism in Flit. Python packaging as a whole has been moving away from that in favour of entry points for some time (e.g. see discussion on https://github.com/pypa/pip/issues/2596). It will probably never entirely go away, but Flit doesn't aim to support every feature of Python packaging. So if you want to include non-Python scripts in a Python package, you'll need to use another packaging tool.
@takluyver thanks for the prompt reply. I didn't realize that PEP 621 specified it this way. Does flit offer a way to use another packaging tool for a sub-package (and merge at the wheel level)? I'd hate to have to either migrate the package away from flit
or create another package entirely and make it a dependency but those seem like the only options now.
No, sorry, it doesn't. A major aim for Flit is to be simple, and options to delegate part of packaging to another tool are kind of the opposite of that. :wink:
There are various tools now which offer a similar packaging experience to Flit for simple cases but with more flexibility. Hatch and Poetry are two that are popular. I don't know whether or how they support scripts as files, but in general they aim to provide more flexibility than Flit does.
python-packaging supports both console scripts and shell scripts: https://python-packaging.readthedocs.io/en/latest/command-line-scripts.html#the-scripts-keyword-argument
flit uses the term "scripts" to refer to "console-scripts". Is there a plan to support non-python scripts (like shell scripts). If so, what will be the interface? A convention for the path to the script to indicate that it's not a console script?