<div dir="ltr">I'm also a visual studio code fan. It is the first editor I've tried that feels lightweight like Vim but has the power of many plugins. That, and the text rendering is excellent.<div><br></div><div><a href="https://pypi.python.org/pypi/Stallion">https://pypi.python.org/pypi/Stallion</a> is a lovely GUI package manager.<br></div><div><br></div><div>One possibility to consider is that virtualenv itself is a bad idea. Why should the Python interpreter executable, rather than the program being run, determine the set of packages that is available for import? It is confusing and inconvenient to have to deal with environments at all. Yes, even if you are using a helper. Maybe there can be a better way to manage dependencies that is not completely disjoint from setup.py.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 16, 2016 at 8:07 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On 16 December 2016 at 20:57, Glyph Lefkowitz <span dir="ltr" class="gmail_msg"><<a href="mailto:glyph@twistedmatrix.com" class="gmail_msg" target="_blank">glyph@twistedmatrix.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg">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?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This might all be way too much work, but I think it's important to remember it's possible.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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*.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">XCode usability benefits from being Apple-centric. Ditto for Visual Studio and MS.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">[1] <a href="http://rodeo.yhat.com/docs/" class="gmail_msg" target="_blank">http://rodeo.yhat.com/docs/</a><br class="gmail_msg"></div><div class="gmail_msg">[2] <a href="http://codewith.mu/" class="gmail_msg" target="_blank">http://codewith.mu/</a><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><span class="m_-2115827976311510703gmail- gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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:<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- their default focus is on managing one environment per device<br class="gmail_msg"></div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">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...</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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. <br class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><span class="m_-2115827976311510703gmail- gmail_msg"></span><span class="m_-2115827976311510703gmail- gmail_msg"></span><div class="gmail_msg">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 :).</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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.<br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><span class="m_-2115827976311510703gmail- gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">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" ;-).</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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).<br class="gmail_msg"></div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">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?</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.<br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg">"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 <i class="gmail_msg">limiting factor</i> 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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 ;).</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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 :)<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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:<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">1. Install VSCode<br class="gmail_msg"></div><div class="gmail_msg">2. Install the "New to Python" plugin<br class="gmail_msg"></div><div class="gmail_msg">3. Run the plugin's "Setup Python Environment" command<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Cheers,<br class="gmail_msg"></div><div class="gmail_msg">Nick.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">[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 :)<br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><br clear="all" class="gmail_msg"><br class="gmail_msg">-- <br class="gmail_msg"><div class="m_-2115827976311510703gmail_signature gmail_msg">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" class="gmail_msg" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>
_______________________________________________<br class="gmail_msg">
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" class="gmail_msg" target="_blank">Distutils-SIG@python.org</a><br class="gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br class="gmail_msg">
</blockquote></div>