> On Dec 15, 2016, at 9:23 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 16 December 2016 at 14:29, Glyph Lefkowitz <gl...@twistedmatrix.com > <mailto:gl...@twistedmatrix.com>> wrote: >> On Dec 15, 2016, at 8:18 PM, Nick Coghlan <ncogh...@gmail.com >> <mailto:ncogh...@gmail.com>> 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.
None of what you're saying is wrong here, so I don't want to disagree. But, I think this is just one perspective; i.e. moving to a cloud environment is one approach to providing a more circumscribed environment, but embracing endpoint sandboxing is another. For example, learning how to use Xcode is a fundamentally different (and easier!) sort of experience than learning the traditional UNIX development pipeline, due in large part to the fact that it provides a unified, discoverable interface. This is despite the fact that Xcode projects are actually substantially more complex than their UNIX-y equivalents, due to the high levels of coupling and complexity in the way that you have to interface with certain system services (signing with entitlements, bundle metadata, etc). You still have to retrieve many resources from the cloud - simulators, documentation, SDKs - but the UI tells you that you need those things, and straightforwardly automates the process of getting them. Everything else that goes into a development project is not "environment setup", but a part of the Xcode project itself. Similarly, version control (a git repository) is nearly implicitly a part of the project. It's tricky to even create one without a VCS backing it any more. Anyhow, Xcode is far from perfect - many of the places it touches the UNIX pipeline are extremely sharp edges you can easily impale yourself on (and don't get me started about codesigning) - but it nevertheless points at a different potential direction. For example; why expose the concept of a "virtual environment" directly at all? "New Project" could just create a requirements.txt and a setup.py for you, alongside a git repo and a virtualenv for that project. Or, the UI could be geared towards setting up a tox.ini rather than a virtualenv, and run everything through tox so it's in an isolated environment with defined requirements. This is a best practice anyway so why not make it easier to start early? This might all be way too much work, but I think it's important to remember it's possible. > 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 In the analogous Python tool, one could replace "per device" with "per project" - and perhaps have a "default project" so something useful could happen even before you've decided what you're doing... > - they both may require environment restarts for changes to take effect ... one could just put a little blinking red light on any jupyter windows whose kernels need to be restarted :) ... > - 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 I thought this thread was already interminable, I look forward to reading the never-ending rest of it now that you've raised the grim spectre of the PyPI user-ratings feature from the dead :). > 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). I initially wanted to disagree when I read this, but I'm not actually sure what educational contexts you're talking about, and why "accountability" is important? > 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 :) Oops. I meant to say "UI". "beginner" is a direction, and not a fixed position; many people more "beginner" than the current audience could be well-served by a discoverable initial project-creation and REPL UI. While I don't doubt that some backend pieces might help (although I still don't see how the one being discussed would), I also think that it would be very hard to say that the back-end is a limiting factor in UX improvement for the Python onboarding process; the front end could move quite a bit up the value chain without touching any of the various backends it would need to interact with. But of course, if I really wanted to make this point, I'd just write it; dstufft is certainly right that volunteer time is not fungible. If I'm lucky, I'll have the time to do that at some point, since my efforts to convince someone else that this is the high-value target have been failing for some years now ;). -glyph
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
