"Alternatively, I've recently started using Visual Studio Code as my editor for
work ..."
FWIW, the long-term Python story in VSCode is currently (largely) one of my
responsibilities, and that bootstrapping flow is exactly one of the pieces I
really want to put in. Unfortunately, nobody has let me have any engineers to
implement it yet :( (mostly for big-company-politics reasons, rather than
hiring trouble)
Top-posted from my Windows Phone
-----Original Message-----
From: "Nick Coghlan" <ncogh...@gmail.com>
Sent: 12/16/2016 5:08
To: "Glyph Lefkowitz" <gl...@twistedmatrix.com>
Cc: "Barry Warsaw" <ba...@python.org>; "DistUtils mailing list"
<Distutils-Sig@python.org>
Subject: Re: [Distutils] Maintaining a curated set of Python packages
On 16 December 2016 at 20:57, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
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.
Yeah, I think we agree more than we disagree here. The main thing is that one
of the key ways newcomer-friendly environments make themselves more
approachable is to *constrain choice*.
XCode usability benefits from being Apple-centric. Ditto for Visual Studio and
MS.
Linux and Python, by contrast, were both born out of a DIY culture where folks
being free to choose their own tools was initially perceived solely as a highly
desirable feature, rather than as a potential barrier to entry for newcomers.
That means there's an argument to be made that something like YHat's Rodeo [1]
might be a better starting point for data analytics in Python than jumping
straight to Jupyter Notebook, and it's also why the Mu editor [2] exists as a
dedicated tool for folks learning Python by way of the micro:bit project.
[1] http://rodeo.yhat.com/docs/
[2] http://codewith.mu/
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...
But we've immediately bumped the complexity level up in doing so, and it's a
level of complexity that many people initially spending all of their
development time on a single project may not need.
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 :).
All the arguments against integrating user ratings into a service that's
focused on lowering barriers to publication still hold, so I'm really just
noting that that decision to create a friendlier publishing environment *does*
introduce some additional constraints elsewhere in the distribution pipeline.
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?
Schools, mainly. Lots of administrators are still scared of the internet, so
one of the attractions of things like Raspberry Pi is that the software updates
come from Debian rather than directly from the software publishers.
Sometimes you can get away with "What the bureaucracy doesn't know won't hurt
it", but it's more convenient when teachers don't have to do that.
"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 ;).
I'll confess that one of my ulterior motives for encouraging computing teachers
to engage more directly with the upstream Python community is that I kinda hope
we'll eventually run into one that either decides none of the current editors
are good enough and creates their own, or else decides that "create the
introductory editor that you wish you had when you started learning to program"
might make a good collaborative student project :)
Alternatively, I've recently started using Visual Studio Code as my editor for
work [1], and it seems likely that would be hackable enough for someone to
create a plugin that bootstrapped a complete Python toolchain such that the
bootstrapping flow became:
1. Install VSCode
2. Install the "New to Python" plugin
3. Run the plugin's "Setup Python Environment" command
Cheers,
Nick.
[1] Oh the irony that the first cross-platform editor I've tried that I
actually think looks nice and find pleasant to use on Fedora was released by
Microsoft :)
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
