Package: setupmeta
Simplify your setup.pyWriting asetup.pytypically involves lots of boilerplate and copy-pasting from project to project.This package aims to simplify that and bring someDRYprinciple to pythonpackaging.
Here’s what your (complete, and ready to ship to pypi)setup.pycould look like withsetupmeta:from setuptools import setup

setup(
    name="myproject",
    versioning="distance",          # Optional, would activate tag-based versioning
    setup_requires="setupmeta"      # This is where setupmeta comes in
)And that should be it -setupmetawill take it from there, extracting everything else from the rest of your project
(following typical conventions commonly used).You can use theexplaincommand (seecommands) to see whatsetupmetadeduced from your project,
for the above it would look something like this (you can see which file and which line each setting came from,
note that a lot of info is typically extracted from your project, if you follow usual conventions):~/myproject: python setup.py explain

          author: (auto-adjust     ) Your Name
              \_: (myproject.py:7  ) Your Name<your@email.com>
    author_email: (auto-adjust     ) your@email.com
     description: (README.rst:1    ) First line of your README
    entry_points: (entry_points.ini) [console_scripts] ...
install_requires: (requirements.txt) ["click", ...
         license: (auto-fill       ) MIT
long_description: (README.rst      ) Long description would be your inlined README
            name: (explicit        ) myproject
      py_modules: (auto-fill       ) ["myproject"]
  setup_requires: (explicit        ) ["setupmeta"]
         version: (git             ) 1.2.3.post2
      versioning: (explicit        ) distanceSeeexamplesfor more.Note:setupmeta’s versioning is based on:git describe --dirty --tags --long --first-parent --match 'v*.*'

# Then, if above yields nothing, we try the more vague '*.*'

git describe --dirty --tags --long --first-parent --match '*.*'you will needgit version >= 1.8.4if you wish to usesetupmeta’s versioning capabilities.GoalThe goal of this project is to:Allow to write very short (yet complete)setup.py-s, without boilerplate, and encourage good commonpackagingpracticesPoint out missing important info (example: version) insetup.py explainSupport tag-basedversioning(likesetuptools_scm, but with super simple configuration/defaults and automatedbumpcapability)Provide usefulCommandsto see the metadata (explain),version(including support for bumping versions),cleanall, etcHow it works?Everything that you explicitly provide in your originalsetuptools.setup()call is taken as-is (never changed),
and internally labelled asexplicit.
So if you don’t like something thatsetupmetadeduces, you can always explicitly state it.nameis auto-filled from your setup.py’s__title__(if there is one, sometimes having a constant is quite handy…)packagesandpackage_diris auto-filled accordingly if you have a<name>/__init__.pyorsrc/<name>/__init__.pyfilepy_modulesis auto-filled if you have a<name>.pyfileentry_pointsis auto-filled from fileentry_points.ini(bonus: tools like PyCharm have a nice syntax highlighter for those)install_requiresis auto-filled if you have arequirements.txt(orpinned.txt) file,
pinning is abstracted away by default as percommunity recommendation, seerequirementsfor more info.tests_requireis auto-filled if you have atests/requirements.txt, orrequirements-dev.txt,
ordev-requirements.txt, ortest-requirements.txtfiledescriptionwill be the 1st line of your README (unless that 1st line is too short, or is just the project’s name),
or the 1st line of the first docstring found in the scanned files (see list below)long_descriptionis auto-filled from your README file (looking forREADME.rst,README.md,
thenREADME*, first one found wins).
Special tokens can be used (notation aimed at them easily beingrst comments):.. [[end long_description]]as end marker, so you don’t have to use the entire file as long description.. [[include<relative-path>]]if you want another file included as well (for example, people like to addHISTORY.txtas well)these tokens must appear either at beginning/end of line, or be after/before at least one space characterversioncan be stated explicitly, or be computed from git tags usingversioning=...(seeversioningfor more info):Withversioning="distance", your git tags will be of the formv{major}.{minor}.0,
the number of commits since latest version tag will be used to auto-fill the “patch” part of the version:tag “v1.0.0”, no commits since tag -> version is “1.0.0”tag “v1.0.0”, 5 commits since tag -> version is “1.0.5”if checkout is dirty, a marker is added -> version would be “1.0.5.post5.dirty”Withversioning="post", your git tags will be of the formv{major}.{minor}.{patch},
a “post” addendum will be present if there are commits since latest version tag:tag “v1.0.0”, no commits since tag -> version is “1.0.0”tag “v1.0.0”, 5 commits since tag -> version is “1.0.0.post5”if checkout is dirty, a marker is added -> version would be “1.0.0.post5.dirty”Withversioning="build-id", your git tags will be of the formv{major}.{minor}.0,
the number of commits since latest version tag will be used to auto-fill the “patch” part of the version:tag “v1.0.0”, no commits since tag,BUILD_ID=12-> version is “1.0.0+h12.g123”tag “v1.0.0”, no commits since tag,BUILD_IDnot defined -> version is “1.0.0+hlocal.g123”tag “v1.0.0”, 5 commits since tag,BUILD_ID=12-> version is “1.0.5+h12.g456”tag “v1.0.0”, 5 commits since tag,BUILD_IDnot defined -> version is “1.0.5+hlocal.g456”if checkout is dirty, a marker is added -> version would be “1.0.5+hlocal.g456.dirty”Use thebumpcommand (seecommands) to easily bump (ie: increment major, minor or patch + apply git tag)Version format can be customized, seeversioningfor more infoversion,versioning,url,download_url,bugtrack_url,license,keywords,author,contact,maintainer,
andplatformswill be auto-filled from:Lines of the form__key__ = "value"in your modules (simple constants only,
expressions are ignored - the modules are not imported but scanned using regexes)Lines of the formkey: valuein your docstringFiles are examined in this order (first find wins):setup.py<package>.py(mccabefor example)<package>/__about__.py(cryptographyfor example)<package>/__version__.py(requestsfor example)<package>/__init__.py(changes,arrowfor example)src/is also examined (for those who like to have their packages undersrc)URLs can be simplified:ifurlpoints to your general github repo (like:https://github.com/codrsquad),
thenameof your project is auto-appended to itrelative urls are auto-filled by prefixing them withurlurls may use{name}and/or{version}markers, it will be expanded appropriatelyauthor,maintainerandcontactnames and emails can be combined into one line
(setupmetawill figure out the email part and auto-fill it properly)i.e.:author: Bob D bob@example.comwill yield the properauthorandauthor_emailsettingsThis should hopefully work nicely for the vast majority of python projects out there.
If you need advanced stuff, you can still leveragesetupmetafor all the usual stuff above, and go explicit wherever needed.