Repository: getnikola/nikola

Issue:
Replace ghp-import2 by ghp-import?
c.f. comments by author of ghp-import2 @ionelmc from https://github.com/conda-forge/staged-recipes/pull/13605#issuecomment-757556835

> Hello everyone, ghp-import2 is basically ghp-import + proper packaging and a couple integration tests. Looks like ghp-import is maintained as of last year and has some bugfixes and the prefix option (packaging and testing is still trash tho). I don't really want to maintain ghp-import2 - I just made it cause ghp-import was dead and horrendously broken packaging-wise 4 years ago.

Edit: links:

* [ghp-import](https://github.com/c-w/ghp-import)
* [ghp-import2](https://github.com/ionelmc/python-ghp-import)


Discussion:
> packaging and testing is still trash tho

This should be evaluated further… @ickc, patches to switch to `ghp-import` and possibly their new [Python interface](https://github.com/c-w/ghp-import#python-usage) are welcome (although they might not be accepted if `ghp-import` turns out to be unsatisfactory).
Packaging is not a problem if you're repackaging anyway. I'd say you should use c-w/ghp-import.
> if you're repackaging anyway

The "repackaging" effort I made in conda-forge is not Nikola's official effort. (And I would like the conda recipe follow Nikola's setup.py as close as possible.)

To me the easiest way would be for the conda-forge folks to accept ghp-import2 there. So if we want Nikola to stick to ghp-import2 I'll try to convince them.

May be it is a question to @ionelmc if it is something you'd keep alive or if you would recommend all people using ghp-import2 to migrate to ghp-import instead. I'd lean more towards having something better tested and continue to work even if it might not have the "cutting-edge" from upstream. (But I don't have experience in using either lib.)
As explained, I only made it cause at that time ghp-import was unmaintained and broken. I only have 1 success path integration test - it's not a lot of testing lol. You should test stuff anyway and don't take anyone's word for it :-)
> You should test stuff anyway and don't take anyone's word for it :-)

Easier said then done, it is my dependency's extra dependency where if it doesn't work I'd replace it with tried and trusted shell one liner in my old setup. But I understand that many people carelessly put many stuffs out there that sort of works but is not well tested and close to unmaintainable. And you get older you'll find that there's only so much you can do and can't fix everything in the world, including testing other's package that they should have tested well in the first place.

But, may be we should also acknowledged that doing stuffs like that is very difficult to test as it is inherently very stateful. And, despite the lack of tests it works.
FYI, because conda-forge won't accept ghp-import2, the conda-forge recipe will optionally depends (`run_constraint`) on ghp-import instead, which I tested locally.

See https://github.com/conda-forge/nikola-feedstock/pull/3

Resolving patch:
diff --git a/nikola/plugins/command/github_deploy.py b/nikola/plugins/command/github_deploy.py
--- a/nikola/plugins/command/github_deploy.py
+++ b/nikola/plugins/command/github_deploy.py
@@ -50,7 +50,7 @@ def check_ghp_import_installed():
     except OSError:
         # req_missing defaults to `python=True` — and it’s meant to be like this.
         # `ghp-import` is installed via pip, but the only way to use it is by executing the script it installs.
-        req_missing(['ghp-import2'], 'deploy the site to GitHub Pages')
+        req_missing(['ghp-import'], 'deploy the site to GitHub Pages')
 
 
 class DeployFailedException(Exception):


Test patch: