On 23 February 2017 at 13:47, Nick Coghlan <ncogh...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
