やってみる

アウトプットすべく己を導くためのブログ。その試行錯誤すらたれ流す。

PyPIパッケージ構成(必要なもの)

 なにが必要かわからんかったので調べた。

情報源

PyPIパッケージ

  • {PypiProjectDirectory}/
    • {package}/
      • __init__.py
      • {module}.py
    • setup.py

 {}で囲われているものは好きな名前でOK。おそらく、上記{}3種はすべてそのプロジェクトを一意に指す同一の名前で統一すると思う。

 むしろ別にする理由がわからない。PyPIPythonパッケージの仕様上、他のファイルも含める必要がある。そのせいで仕方なく多数のディレクトリが必要になる。よって共通の名前をつけることになる。という認識。合ってるかは知らん。

options

 さらに追加で以下もあったほうがいい。

  • {ProjectDirectory}/
    • CHANGES.md
    • LICENSE.txt
    • README.md

__init__.py

from {module} import *

__copyright__    = 'Copyright (C) 2020 ytyaru'
__version__      = '0.1.0'
__license__      = 'GNU Affero General Public License Version 3 (AGPL-3.0)'
__author__       = 'ytyaru'
__author_email__ = 'pypi1@outlook.jp'
__url__          = ''

__all__ = ['{module}', ...]

__license__

 ライセンスは色々ある。正直よくわからん。候補は以下。

 とにかく自由にコードを使えることを重んじた最強ライセンスを選んだ。それがAGPL3.0

 GPL系は商業から避けられているっぽい? それくらいコードを自由に使えることを重んじたライセンス。

__url__

 URLはホームページ。専用ページをつくる気がないならGitHubのURLにでもしておくと良さそう。

__version__

 バージョンについてはセマンティック バージョニングを用いる。

アルファ、ベータ版

 正式版の前なら、表現方法は2種類ある。

  • 0.1.0のようにメジャーバージョン値を0にする
  • 1.0.0-alpha.1のようにプレリリース識別子をつける
プレリリース識別子あり
1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha.2
...
1.0.0-alpha.11
...
1.0.0-beta
1.0.0-beta.1
1.0.0-beta.2
...
1.0.0-beta.11
...
1.0.0

 でもこれ、PyPI__version__に指定していいのだろうか? 特にalphaなどのプレリリース識別子。

 semantic-versionというパッケージがあるらしい。これを内部で使ってくれているなら問題なさそうだが。

 そう考えるとプレリリース識別子がないほうがいいのでは? 以下みたいに。

プレリリース識別子なし
0.1.0
0.1.1
0.1.2
0.2.0
...
0.999999.999999
...
1.0.0

 とにかく1.0.0より小さいものは非正式版。アルファだろうがベータだろうが関係ない。こっちのほうが楽そう。

 ただ、正式版の前に公開APIを変更してもメジャー値はあげられないので、ルールがめちゃくちゃになると思う。そこのところどうなの? 適当? それともマイナーに転嫁して繰り下げて運用する?

Pythonにおけるバージョン書式
[N!]N(.N)*[{a|b|rc}N][.postN][.devN]

 セマンティックバージョニングとは別物。やっぱり使えないんじゃんか……。

 +でローカルバージョンもつけられるとか。たぶんCPUなどハードウェアやOSごとのバージョンだろう。

<public version identifier>[+<local version label>]

 PEP440とセマンティックバージョニングの共通部分だけを使おう。ベータ版は0.1.0のようにプレリリース識別子がない形式にするのが良さそう。

setup.py

import setuptools

with open("README.md", "r") as f:
    long_description = f.read()

setuptools.setup(
    name="textree",
    version="0.1.0",
    author="ytyaru",
    author_email="pypi1@outlook.jp",
    description="",
    long_description=long_description,
    long_description_content_type="text/markdown",
    keywords="tree,text,mapper,ObjectToTextMapper,serializer,deserializer,generator,convertor",
    url="",
    download_url="",
    packages=setuptools.find_packages(),
    classifiers=[
        "Development Status :: 4 - Beta",
        "Programming Language :: Python",
        "Programming Language :: Python :: 2.7",
        "Programming Language :: Python :: 3",
        "License :: OSI Approved :: GNU Affero General Public License v3",
        "Operating System :: OS Independent",
        "Intended Audience :: Developers",
        "Topic :: Utilities",
    ],
    python_requires='>=2.7',
)

 download_urlGitHubのURLにしておくとダウンロード数を合算できそう。GitHubAPIも使えるだろうからいい感じになるはず。

classifiers

 一覧は以下。

 グループの中からそれぞれ適当に選べばいいんじゃない? よくわからんけど。複数選べるものもあれば、ひとつしか選べないものもあるらしい。どれがどれだかわからん。

Development Status

Development Status :: 1 - Planning
Development Status :: 2 - Pre-Alpha
Development Status :: 3 - Alpha
Development Status :: 4 - Beta
Development Status :: 5 - Production/Stable
Development Status :: 6 - Mature
Development Status :: 7 - Inactive
key 意味 概要
Planning 計画 まだ実装すらしていない段階
Pre-Alpha プレアルファ版 アルファ版の前。よくわからんが、とにかくコードを書いてアップしたときの版?
Alpha アルファ版 テスターや開発者向け。未実装やクラッシュなど多数のバグがありうる
Beta ベータ版 ユーザに試用してもらうことでバグや使い勝手を募ることで改善し、正式版へ反映する。
Production/Stable 製品版/安定版 エンドユーザがまともに使える版
Mature 成熟 レガシー化したらこれにする?
Inactive 非活性 別のプロジェクトにしたらこれにする?

所感

 これらをすべて用意するには相当に骨が折れる……。自動化もなさそう。

対象環境

$ uname -a
Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux