The -D option to `install` is not portable. Abstract out the `install` binary
used so that other platforms can use e.g. ginstall to circumvent this problem.
Signed-off-by: Aaron Madlon-Kay <aaron@madlon-kay.com>
When packaging applications, the application is commonly installed into
a different location than it will end up on the users system. While
`prefix` can control where the files will be installed, it also affects
the location the `git_filter_repo` symlink points to. If the files are
then installed in a different location, the symlink is broken.
`DESTDIR` is a de facto standard variable to control where files are
installed, so that prefix can be used to specify where the files end up
on the end-users system. This allows a usecase like `make install
prefix=/usr DESTDIR=pkg`.
Signed-off-by: Kevin Daudt <me@ikke.info>
cp requires the destination directories to already exist. If they do not
exist, it will fail. When packaging applications, it's common they are
installed in an empty directory where the expected directory structure
does not exist yet.
Use `install -D` to copy the files to copy the files so that parent
diretories are automatically created.
Signed-off-by: Kevin Daudt <me@ikke.info>
So that we don't have to run with coverage if we don't want to.
Additionally, don't require being in the t directory to run tests
Signed-off-by: Stefano Rivera <stefano@rivera.za.net>
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>
- correct paths to including missing "Documentation/" prefix
- use fully specified "origin/docs" branch in case the "docs" branch is
not checked out locally
Signed-off-by: Benoit Fouletier <bennews@free.fr>
Aaron Madlon-Kay
Kevin Daudt
erickeller
Elijah Newren
Stefano Rivera
Julian Berman
Benoit Fouletier