[Pythonedu-wg] The installation and deployment experience

[Caleb Hattingh]

On 19 May 2016 at 00:01, Stewart Watkiss <stewart at penguintutor.com> wrote:

> Hi Caleb,
>
> Do you mean to send this just to me rather than to the PythonEdu list?
> It's certainly a valid discussion for the list if you want to repost it
> there.
>
Hi Stewart

Oops!  Yes, I meant to reply to the list.  I should not do email late at
night :)

If people want to follow, hopefully it's not too confusing to have to first
read the copied message below this one.

> ...so that they can only run executables from the trusted folders, so they
> would not be able to run an executable from their home / document folders.
>
This means involvement from support services is unavoidable regardless of
the final solution.

> If they could then it would require a full copy of the python interpreter
> in every user's home folder which would not be ideal.
>
I disagree: I think this is exactly ideal.  I set up my personal
development this way on every platform, Windows, Linux and Mac.
 (Admittedly with Anaconda Python + Conda virtualization rather than
WinPython, but the point stands).  In particular, I make sure to never
interfere with the "system" Python installation in any way.  This is a best
practice.  Many people do this via virtualenv (using the system Python as
the base), but I don't think teaching students virtualenv just for the
purpose of getting a Python working is a good idea.

Could you say why you regard this as non-ideal?

> In terms of the installer then it's about trying to install into the
> Python library folder which could be in program files or in it's own
> folder.
>
Why though? Python can also be in its own folder inside the users home
folder.  If a user messes up the installation, recovery is as simple as
deleting the Python folder and copying a fresh one in.

> There should not be any need to add anything to the start menus.
>
Agree.

> If we can get the official python package maintainers to create the
> installers then that's going to be even better.
>
I'm extremely pessimistic about the core dev team doing anything more than
what is currently provided at python.org.  Everything that is currently
being done is largely volunteer work and they already have too much of it.
The other problem is even bigger: the core team are way too far from the
problem domain, i.e., education environments, and the unique challenges
that go with that. I'd much rather have educators drive requirements.

And more importantly: WinPython already exists, and is already supported.
Why would it not be used, even merely as a starting point? If a new bundled
distribution was made, how would it be any different?

> I restarted the thread recently hadn't really made any progress (as I said
> previously there have been many valid reasons).
>
The problems are hard problems!  What is interesting to me about edu as a
domain, is that here you really can't expect your users to work around
difficulties in your software.  Python packaging and distribution is
regarded by many (even experienced) developers as difficult; the reasons
are the same as what we're now discussing, it's just that our threshold for
what we now expect a user to deal with has lowered.

>
>
> On 2016-05-18 12:01, Caleb Hattingh wrote:
>
> On 18 May 2016 at 19:52, Stewart Watkiss <stewart at penguintutor.com> wrote:
>
>>
>> That'll mean pre-packaged, certified and checked installers for all sorts
>>> of weird and wacky Windows environments.
>>
>>
>> So sounds like the simplest way in terms of getting the packages
>> installed is to have a single Windows install package (msi) that can be
>> handed to the appropriate IT administrators for them to install.
>
>
> There is a distribution called Winpython (https://winpython.github.io/)
> that is easily installable and doesn't require admin privileges.  It can be
> installed in "portable" mode, which is really just decompression, and you
> can drag-and-drop the folder between computers, or pass around a memory
> stick.  The *best* thing about Winpython is that its package manager
> installs pre-built binaries for libraries that require that, so you almost
> never need a compiler available for most packages (it draws from the
> Windows binary collection of modules that Christoph Gohlke has
> energetically maintained for years and years).
>
> I see that now it has also started distributing a "Zero" version, which is
> much smaller and seems to be a minimalist distribution for education:
>
>
> https://github.com/winpython/winpython/blob/master/changelogs/WinPythonZero-3.4.4.2.md
>
> Do note, however, that it includes a *graphical* package installer so you
> (or your students) can point-and-click install extra packages.  This
> project has a reasonably long history; it is unlikely that another effort
> to produce a bundled, admin-rights-free, Python distro on Windows is going
> to end up with a better result.
>
> There is a list of downloads (including the "Zero" builds) on the github
> releases page here:
>
> https://github.com/winpython/winpython/releases
>
>
>> I don't actually have any experience with creating Windows install files,
>> but it doesn't look it should be too difficult - famous last words :-).
>
>
> I have a fair bit of experience with InnoSetup:
>
> http://www.jrsoftware.org/isinfo.php
>
> It is quite a bit easier to create an installer than you might expect.
> The problems come in dealing with the differences between different
> versions of Windows, assuming your installer wants to integrate into the
> "Program Files" and "Start Menu" structures in the correct way.  This is
> why bundles that don't need admin rights and can run from the "Documents"
> folder are much easier.
>
> Finally: I haven't personally used Windows in a while, and it makes me
> nervous to recommend things and ways of working that I don't use myself; I
> have not used Python at all on Windows 10, for example.  As Nicholas said,
> it is probably a good idea to pay attention to what active Pythonistas on
> Windows are doing.
>
> rgds
> Caleb
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonedu-wg/attachments/20160519/cc10c988/attachment.html>