[Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

[Guido van Rossum]

Could I summarize that as "software integrators build from source, while
end users use an installer"? And the rest of the discussion is about which
installer (in the widest sense of the word) to recommend, where the choices
include Linux vendor distros, sumo Python distros, Mac/Win installers, as
well as fine-grained tools like apt-get (Linux vendor specific) and pip and
conda (Python specific)? And perhaps conda is pushing the boundaries
because it also tries to manage things that aren't strictly Python, but
useful for scientists?


On Fri, Apr 18, 2014 at 8:58 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 16 Apr 2014 21:03, "R. David Murray" <rdmurray at bitdance.com> wrote:
> > There is an 'Installing Python on Windows' link further down the google
> > results that links to a fairly good page from python-guide.org, whose
> > first link lets you download the 2.7.6 msi.  I guess that's the 32
> > bit version.  But it then tells you go to python.org to make sure you
> > get the latest release, and tells you to click on a link that doesn't
> > exist any more (the "windows installer" link).
> >
> > So, yeah.
> >
> > Usability.
>
> As part of thrashing out the respective distribution ecosystem roles
> of pip and conda (still a work in progress), we're at least converging
> on the notion that there are actually now *two* main ways of consuming
> Python: as a "software integrator" (the way most of us have
> traditionally consumed it, and the way that dominates most project
> documentation outside the scientific Python community) and as an "end
> user" (the way Linux system administrators have long consumed it, and
> the way scientists, financial analysts and folks just learning Python
> are likely best off consuming it).
>
> Making these different personas explicit is a process that has barely
> begun (this email is mostly based on some conversations I had in
> person at PyCon and via email during the sprints), but here's the gist
> (based on listing examples):
>
> Software integrators:
>
> * Linux distributions and other operating system vendors
> * Sumo redistributions (commercial or otherwise)
> * "Python based environments" (PTVS, Enthought Canopy, wakari.io,
> Python Anywhere, etc)
> * Software-as-a-Service developers
> * Device manufacturers
> * PC OEMs
> * creators of corporate "Standard Operating Environment" definitions
> * System integrators (IBM, Boeing et al)
> * Application developers (from simple CLI tools to OpenStack)
>
> End users:
> * system administrators
> * scientists (whether in academia or corporations)
> * financial analysts
> * engineers
> * data miners
> * graphic artists
> * animation designers
> * <<< Folks trying out Python for the first time >>>
>
> For end users, Python is likely consumed as *part of something else*.
> For Linux admins, it's a way of scripting the system, for graphic
> artists and animators, it's likely embedded as part of a tool like
> Blender or Maya, for scientists, financial analysts, engineers and
> data miners, it likely makes sense to use it as part of a larger
> visualisation environment like IPython Notebook, Python (x, y),
> Enthought Canopy, or a hosted system like Wakari or Python Anywhere.
>
> Folks just learning Python are also in the latter list, and we
> currently ask them (on the python.org download pages) to jump straight
> into the "software integrator" role to get their environment set up,
> rather than setting out to impress them by recommending one of the
> pre-integrated sumo distributions that offers quick and easy access to
> powerful visualisation and data analysis tools. While providing access
> to the CPython default interactive prompt in the browser is cool, it's
> less impressive as the default experience we provide after someone has
> downloaded and installed the interpreter. Instead, we likely want to
> *really* impress them by making it easy for them to explore the full
> power of things like IPython Notebooks. My own current preferred
> approach for that is the fully open source "Anaconda" distribution
> from Continuum Analytics, specifically because it *is* fully open
> source, and you can "pip install conda" to bootstrap their package
> manager in other contexts. And, importantly, because conda
> environments can *manage the Python runtime itself*, it is able to
> work more consistently across different platforms than the upstream
> tools by reliably isolating itself from the system Python on POSIX
> platforms. It should even by possible to get conda to manage alternate
> Python implementations like Stackless, PyPy, Jython, IronPython, etc
> (although I don't believe anyone is using it that way as yet).
>
> However, conda *isn't* optimised for the software integrator use case
> - the additional work it does to improve cross platform consistency
> actually *gets in the way*, when you're trying to integrate Python
> closely with a larger system (like a Linux distribution), and "a large
> set of automatically provided libraries" isn't actually a feature in
> that context. While conda does offer some options (like miniconda) to
> make that kind of integration task easier, I strongly believe that
> realm is better handled by consuming CPython and the standard library,
> along with pip and related tools, directly, and accepting the
> additional platform specific details that come along with that.
>
> Making this "software integrator" and "end user" split deliberately
> and consciously, and pushing the former toward consuming things in a
> more DIY fashion, and the latter towards a pre-assembled sumo
> distribution should help greatly in allowing us to better balance the
> starkly different needs of the two groups, and provide an extremely
> high quality "out of the box" experience for new users, while still
> allowing software integrators to dive in and customise things to suit
> their own needs.
>
> From a Python 2->3 migration perspective, blessing at least one sumo
> distribution also provides a way to make it easy to gain ready access
> to backports from the Python 3 standard library (for example, Anaconda
> currently includes at least the backports.ssl_match_hostname module).
>
> Regards,
> Nick.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140418/30fbf209/attachment.html>