Oh, your `sys.version_info` check reminds me of the `python_requires` field of `setuptools.setup`. You can put `python_requires=‘>=3.4’,` maybe after the `long_description` line and get rid of the manual check. pip takes care of the rest. Other than that, LGTM.
`pyproject.toml` is defined in PEP 518. PEP 518 requires both setuptools and wheel; these requirements are further lifted by PEP 517, so that you can use alternative backend such as flit, but PEP 517 is newer (as in accepted later), and I believe pip only supports PEP 518 but not PEP 517 at the moment.
The reason I added a `pyproject.toml` was to ensure wheel as a build dependency. Without wheel, you can’t run `setup.py bdist_wheel`, and `pip install .` uses `setup.py install` (egg-based, rather than wheel-based), and on Windows this causes Unicode command line args to degrade to CP1252 (setuptools issue I linked above). In practice though, pip at the moment still requires wheel to be installed beforehand, despite installing wheel in the build environment, so this pyproject.toml doesn’t accomplish much in the current state of python packaging.
In short, the `pyproject.toml` is not necessary, but it could be future-proof.
Well, publishing to PyPI is trivial and can be done with a one-liner:
./setup.py sdist && ./setup.py bdist_wheel && version="$(git describe --abbrev=0)" && twine upload dist/googler-${version#v}.tar.gz dist/googler-${version#v}-py3-none-any.whl
The problem is that the name `googler` is already taken.
Windows packaging
=================
I created a Chocolatey package: https://chocolatey.org/packages/googler.
As a Windows n00b submitting the first package, I'm not sure how it'll turn out.
Make googler installable with pip
=================================
This PR makes googler installable with pip. TLDR: I decided to discard this work in the end. Keeping a copy around just in case.
Rationale: Recently I was porting a few of my Python apps to Windows, and I managed to figure out the pain points of (pure) Python packaging on Windows. To name a few:
1. You can't add a shebang and the x bit to a text file and magically make it executable. A big fuck you to scripting (and especially, calling scripts from scripts).
2. The above can be alleviated by https://docs.python.org/3/faq/windows.html#how-do-i-make-python-scripts-executable, but it does NOT solve all problems. For one, `.py` in `PATHEXT` can't be guaranteed (but the CPython installer does add `.PY` to `PATHEXT`[1], so that's probably a mostly safe assumption). And even then, the script can only be called by name from a console; `os.system`, the `execl/execv` family, `subprocess`, etc. certainly doesn't work.
3. No standard installation location (not that I know of anyway). On *nix we have FHS, we have `/usr/local/bin`. On Windows what do you have? Program Files? Do you just create a `C:\bin`? Unclear.
4. Open files cannot be renamed (unless certain flags are set, it seems) or removed. Forget in-place upgrade, even pip can't upgrade itself. In practice, hunting for the process that's hanging on to a file is a regular occurrence. It's like hunting for the process that blocks unmounting, but for every single file. Good grief.
5. Encoding. Oh my god. 30 years of Windows later, Microsoft still hasn't got the memo on globalization.
My initial idea to package googler for Windows is to use setuptools, wheel and pip. (Btw, eggs have serious problems on Windows, as I recently discovered [2]; wheel is the only way to go.) Letting pip provide a console script is the only way I can think of to provide a .exe on Windows that resolves (1) and (2). However, this approach is a bit complicated, and I couldn't find out how to gracefully handle a major Python upgrade (I'm talking about a minor version of Python here), as the console script and site-package is tied to a particular Python 3.x.
Eventually I decided that the console script approach is not worth it; I doubt Windows users are calling googler from scripts, so a `googler.py` is probably good enough.
[1] https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Tools/msi/path/path.wxs#L33
[2] https://github.com/pypa/setuptools/issues/1573