On 16 December 2016 at 14:29, Glyph Lefkowitz <[email protected]> wrote:
> On Dec 15, 2016, at 8:18 PM, Nick Coghlan <[email protected]> wrote: > > At the beginning of your story you mentioned the GUI client - *that* is > the missing piece ;). I've been saying for years that we need a Python.app > that lets you easily bootstrap all this stuff: walk you through installing > C dev tools if your packages need them, present a GUI search interface to > finding packages, present a normal "file->open" dialog for selecting a > location for a new virtualenv, automatically pop open a terminal, launching > a Jupyter notebook whose kernel is pointed at said environment... > It isn't really, as we started looking at this for IDLE, and the entire current UX is just fundamentally beginner hostile: - virtual environments are hard - requirements files are hard - knowing what packages are trustworthy and worth your time is hard - limiting students to a set of "known safe" packages is hard - components that assume command line use are hard They're especially hard if the only way to distribute a fix is to release an entire new edition of CPython rather than having IDLE talk to a (preferably configurable) backend cloud service for updated instructions. So there's a reason so many learning and even full development environments are moving online - they let the service provider deal with all the hassles of providing an appropriately configured environment, while the students can focus on learning how to code, and the developers can focus on defining their application logic. However, the reason I brought up the Curse and Firefox GUI examples was to emphasise the problems they hide from the default rich client experience: - their default focus is on managing one environment per device - they both may require environment restarts for changes to take effect - they both reference an at least somewhat moderated back end (by Curse in the Curse client case, by Mozilla in the Firefox case) - they both incorporate popularity metrics and addon ratings into the client experience Mobile app store clients also share those four characteristics (where "number of installations" and "star ratings" are critically important to search rankings, but gaming the latter is mitigated by hiding the "Write a review" feature if you haven't actually installed the app anywhere) > User-curated package sets strikes me as the _lowest_ priority feature out > of all of those, if we are ordering by priority to deliver a good user > experience. I know "steam curators" have been brought up before - but > we're talking about adding curators (one of my least favorite features of > Steam, for what it's worth) before we've added "install game" ;-). > In many educational contexts, adding "install game" without support for institutional curators of some kind is a complete non-starter (even if those curators are a collaborative community like a Linux distribution, there's still more accountability than software publishing sites like PyPI tend to provide). > Users might even figure out this sort of stuff for themselves if they are > given a discoverable API for things like search and installation of > packages. > That sounds a bit like agreement that we're still missing some of the backend pieces needed to make a beginner-friendly client really viable :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
