[Pythonedu-wg] Fwd: The installation and deployment experience

[Stewart Watkiss]

Hi Nicholas,

I've added more comments in-line.


> On 10/05/16 16:35, Stewart Watkiss wrote:
> > Hi All,
> >
> > This list has been quiet of late, which is quite understandable with all
> > the new things Python and Education related that have been going on. For
> > example MicroPython on the micro:bit (well done to all involved!). For
> > my part I've been writing a book "Learn Electronics with Raspberry Pi".
> > It's due to be released in about a month and includes quite a bit of
> > Python :-)
> >
>
> Congratulations. At what age/experience level is the booked aimed. For
> example, could I let my Sam (11yo, now with his own shed) loose with
> it..? ;-)

It's aimed at older children to young adults designed for beginners in
both electronics and programming focussed more on the electronics side.
Most of the projects are designed for breadboards - with soldering etc
left for the last few chapters. Some of the components sometimes need a
little soldering - eg. Breadboard NeoPixels need the breadboard pins to
be soldered on :-( . One chapter uses Scratch GPIO (includes a project I
ran with a Code Club of 8 to 9 year olds) and the rest is all Python.
You can read the blurb here: http://www.apress.com/9781484218976?gtmf=s
I'm sure Sam would be fine with it. I'm not sure what the rules are from
my publisher (Apress), but I'm sure I should be able to send you a
preview chapter or two when I get the proof back.
> > Now I've got most of my book out of the way I've got a bit more time so
> > I'm keen to get the discussion moving on how we can simplify the
> > installation / deployment experience for Python in the classroom (and at
> > home).
> >
>
> This is a very important topic, not least because it's not just isolated
> to installing Python. In my experience, installing ANYTHING is a royal
> PIA in the classroom. Especially if the equipment is controlled /
> sub-contracted out to ATOS, CAPITA and their ilk.
The schools I've been in tend to use the LEA arrangements where there
are a pool of technicians that the school has access to for 1 afternoon
a week (if they are lucky). I know of some schools that have gone down
the sub-contracted route, but not actually worked with them directly.

>
> Put simply, it appears to be a bit of a "racket" where installing
> *anything* requires inordinate investment of time and effort into an
> expensive and slow moving process.
>
> My hunch is some guerilla type action is required.
>
> (It's why we ensure Mu is a stand-alone executable, so you just have to
> drag and drop it).
Which works well for standalone apps, but not so good for the fully
Python interpreter and all the modules.
> > I've been thinking about this some more, thinking about the issues (or
> > at least what I perceive them to be) and looking at what options are
> > available.
> >
>
> No matter what the options could or should be, the rather large elephant
> in the room is the "racket" described above.
>
> > I think that the initial idea is to have a list of packages that can be
> > pre-installed ready for pupils to use is still a good idea, but I also
> > think we need a way that these can be updated, or that users can install
> > other packages as appropriate. One reason for this is that there is good
> > work on some modules that could greatly help when teaching programming.
> > If these modules are being actively developed then it may mean updating
> > these. For example I'm thinking of Pygame Zero, which is still in its
> > early stages. It provides an easy way to get started with graphical
> > applications, but I expect will include new features in the future.
> >
>
> Other FooBarZero packages are in the works and exactly the same argument
> applies to them too.

Absolutely. I used Pygame Zero as an example as that's something I've
used myself, but there are many others.
Computing moves on so fast compared to many other subjects and so
whatever is installed today could be out-of-date in a few months. I've
experienced a similar thing in the past where I created some (PHP) code
to run on a website to then find it didn't work on my hosted website
because the server had a different version of PHP installed. In schools
the problem can be even bigger with some computers still running Windows
XP. I can only imagine the frustration of kids following a guide from a
magazine where the program won't run because the system hasn't been
updated for several years.

> > Updating the initial install of Python on a school computer may need
> > involvement from the computer administrators which can be an issue.
>
> Bingo.
>
> > Perhaps pyenv provides a potential solution allowing students to install
> > additional modules. As this feature is already included in the recent
> > version of Python then perhaps we just need documentation for the
> > teachers and/or students that will allow them to make use of these
> > features.
> > This won't necessarily help with using Python on a computer without an
> > Internet connection, so perhaps we need this in addition to the
> > pre-installed modules.
> >
>
> I'm more concerned with the rather shonky way in which computers are
> configured at schools. Many are virtualised thin clients and I'm not
> sure how effective yet another environment would be.
I had thought about thin clients, the ones I've seen where desktop PCs
running Windows, although even the head of IT had no admin authority so
was unable to install themselves.
>
> > This is so far mostly my own thoughts from my (fairly limited)
> > experience helping with after school clubs. So I think the first thing
> > is to understand what the problem is and also if anyone else knows of
> > other ways that this could be addressed.
> >
> > * Does anyone have any thoughts they'd like to share on what the issues
> > are?
> > * Do you think I'm thinking along the right lines or not?
> >
>
> Absolutely you're thinking along the right lines... keep it up!
>
> I think much of the problem is a hearts-and-minds issue though. Many
> teachers simply don't have the knowledge to see that shonky
> sub-contracted set-up is sub-standard and a terrible pedagogical platform.
That's something I've been thinking as well. Even where the teachers
know some programming it's unlikely they know enough about the way the
OS is setup to articulate to the admin how it should be setup.
> > My own experience of Python is as someone that has quite a bit of
> > experience programming in Python, but always on a computer that I've
> > been administrator for and mainly on Linux. I normally just install any
> > modules I need and don’t have any experience of the internals of the
> > Python interpreter or PIP. So:
> >
> > * If anyone has other suggestions based on their experience then please
> > share them too.
> >
>
> Make it as simple as possible for installation and updates to happen.
> That'll mean pre-packaged, certified and checked installers for all
> sorts of weird and wacky Windows environments.

Are you saying that the modules should be identified and included in the
install of Python, or as recommended package to install after Python is
installed?

That was certainly my initial thought having a "Python Education
Installer" that is installed after Python is, but it's also getting the
ongoing updates installed that would be an issue - hence the reason I
was thinking of removing some of the dependence on the sys admin. That's
why I was thinking of using the standard install, but having a way for
modules to be easily downloaded and stored in the user's home directory
structure. It sounds like it may not be quite that straight forward :-(

Stewart