It appears that entry_points have replaced scripts in setuptools (and packaging in general?). Is there a standard around this or official doc? pypa/installer won’t install scripts for example, but it will install entry_points. Should scripts be considered deprecated?
I don’t think there’s anything formal. Scripts are not as well supported (as you discovered) and don’t work well on Windows (where .exe
files are the only reliable way of implementing a new command - see here for details). So I’d say that entry points are the better cross-platform solution.
Thanks. Does a call need to be made at some stage? I seem to recall pip at some stage had/has future plans (probably far future) to switch installation logic to pypa/installer. Or is that mostly conjecture on my part?
It doesn’t matter whether pip switches to installer or not — wheels are installed in the same manner, by installer.
The way scripts
in setuptools works is that it dumps the file directly into the scripts scheme. Entry points will dump a wrapper to call the entry point. The main reason to prefer entry points is for cross platform support (as mentioned)
If we want to kill placing raw files in the scripts scheme, we would only be able to do that by breaking backwards compatibility, and one place to do that would be a wheel 2.0 format.
What about fully deprecating/dropping support on the build backend side instead (does anything other than Setuptools actually implement scripts?) That would guide authors to use entry points instead for new releases and projects, while not breaking compatibility with existing releases. @abravalheri does Setuptools have current plans in that regard?
It’s a useful thing on its own — cmake · PyPI puts an executable in there, as part of a correctly tagged wheel. You can’t do that if we drop things on the wheel format level, so… might make sense on a backend level, but setuptools might be too generic a backend to disallow this sort of thing.
Setuptools supports it “as it is”[1]. I don’t think there are plans to drop or improve support for these files.
If I am not wrong, we do recommend in the docs to use entry-points whenever possible.
with all the existing limitations (e.g. incomplete “editable” behaviour) ↩︎
Hi,
Since script-files is marked as deprecated here, is there any intention to have an additional option than entry points, that just copies the files to the path? And maybe explicitly mark it as not recommended for cross-platform compatibility? Scripts has been useful to me. To include some utility shell scripts that sometimes are tremendously quicker to write than Python, and at some NLP projects we directly dismiss Windows support. Or have all the config options to become cross-platform compatible in the future?
script-files
arrayDeprecated equivalent to the script
keyword insetup.py
(should be avoided in favour ofproject.scripts
)
I think you’re referring to this aspect? I think that’s a setuptools-specific question you’ll want to ask setuptools’ maintainers; on their repository’s discussions tab or something.
The underlying difference between the two scripts
vs entry_points -> console_scripts
in setup.py is fairly “easy” to see if you build a wheel and do unzip -l <wheel-file>
.
The files specified in scripts
will end up in the wheel as-is at <project>-<version>.data/scripts/...
. These will end up in the bin/
directory of a Python virtual environment.
The entry_points
specified in console_scripts
will end up in a .txt
file in the metadata folder (.dist-info
) within the wheel. The latter get launcher files generated for them by the installer (i.e. pip) in a cross-platform manner.
The capability to put arbitrary files into the scripts location isn’t going to be taken away because the ability to put files like <project>-<version>.data/scripts/...
isn’t going to be taken away. Whether setuptools supports doing that with their pyproject.toml based configuration is a question for you to ask the setuptools maintainers.
I’ll flag that the scripts
key in setup.py
takes a list of files whereas project.scripts
in pyproject.toml
is a mapping/dictionary/table.