This should make the installation via pip more robust.
On Windows the usage of entry_points will install a wrapper executable
for the script that chooses the proper python executable. This
essentially makes the script run correctly when called via `git
filter-repo` (direct execution via `git-filter-repo` was already fine
before).
This fixes an issue on Windows, where the git-installation will choose a
different python executable than the one indicated by the installation
via `pip{x,3} install`.
Signed-off-by: Benjamin Motz <benjamin.motz@mailbox.org>
Multiple runs of setuptools encounter a FileExistsError exception
trying to re-symlink the same files.
This exception is safe to ignore: the files were already symlinked
so the call can be considered successful.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
Clean up the PyPI dist packages, remove unnecessary files, and
streamline the release process:
* Avoid adding extra unnecessary files to the repo; setup.py is code
and can copy the necessary files into place.
* Make sure README.md is included so we don't get an UNKNOWN
Description field.
* Add a long_description_content_type to avoid parsing errors on the
README.md file and rejecting the upload.
* Define the license and platform fields so they don't show up as
UNKNOWN either.
* Remove unnecessary pyproject.toml. This makes sense for most python
projects, but since I already have a Makefile with installation
rules (because I'm trying to be more compatible with git.git just in
case we ever get merged into it), the pyproject.toml file is
somewhat duplicative. Sure, the Makefile won't specify the exact
versions needed but...meh.
* Split the release target of the Makefile into github_release and
pypi_release substeps, to allow them to be run semi-independently.
Make the pypi_release run a few more steps for me.
Signed-off-by: Elijah Newren <newren@gmail.com>
Benjamin Motz
Sirio Balmelli
Elijah Newren
Julian Berman