[hawkmoth] Re: [PATCH] packaging: add files for python packaging

  • From: Jani Nikula <jani@xxxxxxxxxx>
  • To: Bruno Santos <brunomanuelsantos@xxxxxxxxxxxxxxxxxx>, hawkmoth@xxxxxxxxxxxxx
  • Date: Fri, 14 Dec 2018 18:43:48 +0200

On Fri, 14 Dec 2018, Bruno Santos <brunomanuelsantos@xxxxxxxxxxxxxxxxxx> wrote:

I'll be honest, I have no idea how pip works, so I'll trust you tested it
and it works for you and simply say that it looks OK to me.

Don't tell anyone, I'm pretty clueless on this myself.

I think you could add something to the docs about installing through pip.
Reason being the same I gave for mentioning arch's package.

Agreed, though I want the packaging merged first.

I also had a few comments on the patch. See below.

Cheers

On 12/13/18 10:36 PM, Jani Nikula wrote:
Also add some helpful build targets for packaging.
---
 Makefile       |  2 +-
 Makefile.local | 26 ++++++++++++++++++++++++++
 setup.cfg      |  2 ++
 setup.py       | 42 ++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 71 insertions(+), 1 deletion(-)
 create mode 100644 Makefile.local
 create mode 100644 setup.cfg
 create mode 100644 setup.py

diff --git a/Makefile b/Makefile
index ef5421a0ab9d..1c7d46e0fc9a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 all:
 
-subdirs := test doc hawkmoth
+subdirs := . test doc hawkmoth

 include $(subdirs:%=%/Makefile.local)
 include Makefile.rules
diff --git a/Makefile.local b/Makefile.local
new file mode 100644
index 000000000000..35e5e31f03c8
--- /dev/null
+++ b/Makefile.local
@@ -0,0 +1,26 @@
+# -*- makefile -*-

Ah, modelines, the most telling leak of developer's personal information :p

Seriously though. not every file has it, so I never know if this is
intentional or not.

Frankly the only reason is that emacs doesn't recognize Makefile.local
as a Makefile otherwise. That's the difference between files that have
it vs. not. ;)

If they bug you, I'll take a patch nuking them.


+# Copyright (c) 2018, Jani Nikula <jani@xxxxxxxxxx>
+# Licensed under the terms of BSD 2-Clause, see LICENSE for details.
+#
+# Helpers for packaging and releasing.
+#
+# FIXME: Actually add helpers for releasing...
+#
+
+dir := .

Unused variable?

Just for completeness I guess, to go with the chosen Makefile style
throughout.

Admittedly the whole file is more of a reminder for me how this stuff
works. Just something to get started with. In the end, I want to
automate tagging, releasing, packaging, uploading, etc.


+
+dist-tools:
+    python3 -m pip install --user --upgrade setuptools wheel twine
+
+dist:
+    python3 setup.py sdist bdist_wheel
+
+test-upload:
+    python3 -m twine upload --repository-url https://test.pypi.org/legacy/ ;
dist/*
+
+upload:
+    python3 -m twine upload dist/*
+
+.PHONY: dist-tools dist test-upload upload
+
+CLEAN := $(CLEAN) build dist hawkmoth.egg-info
diff --git a/setup.cfg b/setup.cfg
new file mode 100644
index 000000000000..8183238ab1c7
--- /dev/null
+++ b/setup.cfg
@@ -0,0 +1,2 @@
+[metadata]
+license_files = LICENSE
diff --git a/setup.py b/setup.py
new file mode 100644
index 000000000000..c8a72c7a18f5
--- /dev/null
+++ b/setup.py
@@ -0,0 +1,42 @@
+import setuptools
+
+with open('README.rst', 'r') as file:
+    long_description = file.read()
+
+setuptools.setup(
+    name = 'hawkmoth',
+    version = '0.1.0',
+    author = 'Jani Nikula',
+    author_email = 'jani@xxxxxxxxxx',
+    license = '2-Clause BSD',
+    description = 'Hawkmoth - Sphinx Autodoc for C',
+    long_description = long_description,
+    long_description_content_type = 'text/x-rst',
+    url = 'https://github.com/jnikula/hawkmoth',
+    packages = [
+        'hawkmoth',
+    ],
+    install_requires = [
+        'sphinx',
+        'clang', # depend on distro packaging instead?
+    ],
+    extras_requires = {
+        'dev': ['sphinx-testing'],
+    },
+    python_requires = '>=3', # 3.4?

In that case, I'd like to revisit the relative imports issue. Was there any
other reason to hold that change back other than support Python 2?

I don't think I made myself clear here, allow me to elaborate. I only
wanted to keep supporting python 2 for a very brief transition period,
so that we have a few commits in the git history where both work, and I
could verify everything works using either version. We've got that now,
so I think we're good to go for python 3 only.

To be fixed as a separate patch of course.

Patches welcome! ;)

As for this patch, 3 is ancient, end of life and I don't think many people
use it any more, so maybe 3.4 would be better indeed. I think 3.4 is the
oldest maintained version too. Your call though.

Sounds good, 3.4 it is.

Thanks for the review!

BR,
Jani.


+    classifiers = [
+        'Development Status :: 3 - Alpha',
+        'Framework :: Sphinx :: Extension',
+        'Intended Audience :: Developers',
+        'License :: OSI Approved :: BSD License',
+        'Operating System :: OS Independent',
+        'Programming Language :: Python :: 3',
+        'Topic :: Documentation :: Sphinx',
+        'Topic :: Software Development :: Documentation',
+    ],
+    keywords = 'python sphinx autodoc documentation c',
+    project_urls = {
+        'Documentation': 'https://hawkmoth.readthedocs.io/en/latest/',
+        'Mailing List': 'https://www.freelists.org/list/hawkmoth',
+    }
+)


-- 
Bruno Santos

PGP KEY: 941052CD (pool.sks-keyservers.net)

Other related posts: