Not needed with html5-parser 0.4.6
Modify the test to work with all versions of html5-parser
Fixes#990 (Update testsuite for html5-parser 0.4.6 changes)
Since xdg-mime only cares about basename(filename) and that filename is
an existing file (and we don't know where the installed one is), create
an empty file with the right name and then delete that.
Since installing code will also delete a directory tree, it should run
first. This avoids exotic cases where it deletes the binaries it just
installed.
Use case: co-installing python2/python3 using a bindir bundled with the
rest of calibre's code, in order to maintain an alternatives system
pointing symlinks in /usr/bin at the configured binaries.
The uninstaller is only meant to be used on systems where calibre is
being installed live. For staged installs, it can be assumed that the
same mechanism which takes care of installing files from the staging dir
to live systems, is also able to remove calibre when desired. Usually
this will be a linux package manager.
Injecting the location of the mime_resources file from P() in non-frozen
builds will depend on the mime resource from the source tree rather than
the same location during install time... a source tree which may be
deleted after successful installation. On a frozen build, or when using
'develop' instead of 'install', this path will be the same, and things
just work.
The solution is to add *both* paths, and try to uninstall whichever one
exists.
In order for xdg-utils programs to successfully install resources to the
staging root instead of /usr, this variable needs to be set and
additionally some arcane directories must be created that xdg-utils,
astoundingly, does not know how to just gracefully handle.
xdg-mime is simply hopeless as it does not have a --noupdate flag. When
using a staged install, copy it with shutil instead.
This creates an additional variable containing the version number
extracted from a git checkout via `git describe`, and diverts all
human-readable output to use that via get_version.
The Windows-specific hack initially added in commit
8743efbed1e54d8dd4e71ba71ebd5a7806564270 should be able to be removed
now as it is no longer necessary. The python encoding on Windows is sane
in python3.
