On 23 February 2017 at 14:49, Thomas Kluyver
On Thu, Feb 23, 2017, at 02:28 PM, Paul Moore wrote:
I'd also drop "used to develop and deploy Python libraries, applications, and scripts" - why does what it's used for affect its category?
Things for working on & with Python code often have installation requirements a bit different from other applications. E.g. pip installs (or used to) with aliases specific to the Python version it runs on, so pip, pip3 and pip-3.5 could all point to the same command. Clearly it wouldn't make sense to do that for youtube-dl.
I'm not sure about 'tool' as a name for this category, but they often do require different handling to general applications.
Point taken, but in the absence of a behavioural difference, why not let the author decide? If I wrote "grep in Python", I'd call it a tool, not an application. The author of pyline (https://pypi.python.org/pypi/pyline) describes it as a "tool". For me, command line utilities are typically called tools. Applications tend to have (G)UIs. I don't think we should repurpose existing terms. And unless we're planning on enforcing different behaviour, I don't think we need to try to dictate at all. If we were to add a facility to create versioned names (rather than just having a special-case hack for pip) then I could imagine restricting it to certain package types - although I can't imagine why we would bother doing so - but let's not worry about that until it happens. Or maybe we'd want to insist that pip only allow build tools to have a certain package type (setuptools, flit, ...) but again, why bother? What's the gain? Paul