[Distutils] distlib and wheel metadata

[Paul Moore]

On 23 February 2017 at 13:47, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> Slight amendment here to use the term "library" rather than the generic
> component (freeing up the latter for its usual meaning in referring to
> arbitrary software components). I also realised that we need a separate
> category to cover packages like "pip" itself, and I chose "tool" based on
> the name of the field in pyproject.toml:
>
> ============
>     library: a software component used to build Python applications. Users
> will mainly interact with the component via a Python API. Libraries are
> essentially dynamic plugins for a Python runtime. Examples: requests, numpy,
> pytz
>     tool: a software utility used to develop and deploy Python libraries,
> applications, and scripts. Users will mainly interact with the component via
> the command line, or a GUI. Examples: pip, pycodestyle, gunicorn, jupyter
>     application: an installable client application or web service. Users
> will mainly interact with the service via either the command line, a GUI, or
> a network interface. While they may expose Python APIs to end users, the
> fact they're written in Python themselves is technically an implementation
> detail, making it possible to use them without even being aware that Python
> exists. Examples: ckan (network), ansible (cli), spyder (GUI)
>     metapackage: a package that collects specific versions of other
> components into a single installable group. Example: PyObjC
> ============
>
> I think a package_type field with those possible values would cover
> everything I was worried about when I came up with the idea of the separate
> "integrates" field, and it seems like it would be relatively straightforward
> to explain to newcomers.

Yeah, that looks good. I'd assume that:

(1) The field is optional.
(2) The field is 99% for information only, with the only imposed
semantics being that PyPI can reject use of == constraints in
install_requires unless the type is explicitly "application" or
"metapackage".

Specifically, I doubt people will make a firm distinction between
"tool" and "library". In many cases it'll be a matter of opinion. Is
py.test a tool or a library? It has a command line interface after
all. I'd also drop "used to develop and deploy Python libraries,
applications, and scripts" - why does what it's used for affect its
category? I can think of examples I think of as "tools" that are
general purpose (e.g. youtube-dl) but I'd expect you to claim they are
"applications". But unless they pin their dependencies (which
youtube-dl doesn't AFAIK) the distinction is irrelevant. So I prefer
to leave it to the author to decide, rather than force an artificial
split.

Thanks for taking the time to address my concerns!

Paul