On 23 February 2017 at 22:32, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 23 February 2017 at 18:53, Paul Moore <p.f.moore@gmail.com> wrote:
On 23 February 2017 at 08:44, Nick Coghlan <ncoghlan@gmail.com> wrote:
> That gets us back into the world of defining what the various package types
> mean, and I really don't want to go there :)

And yet I still don't understand what's wrong with "application",
"library", and "metapackage" (the latter saying to me "complex thing
that I don't need to understand"). Those terms are clear enough -
after all, they are precisely the ones we've always used when debating
"should you pin or not"?

Sure, there's a level of judgement involved - but it's precisely the
*same* judgement as we're asking authors to make when asking"should I
pin", just using the underlying distinction directly.

Thinking about it further, I may be OK with that, especially since we can point to concrete examples.

component: a library or framework used to build Python applications. Users will mainly interact with the component via a Python API. Examples: requests, numpy, pytz

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.

Cheers,

Nick.

Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia