Re: [Pythonedu-wg] The installation and deployment experience
On 19 May 2016 at 00:01, Stewart Watkiss <stewart@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@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-...
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
...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.
This is why we are looking at a way to make it easier to provide a package that the administrators (support services) can install, so that it's a one-shot request to install a package then the students can use those libraries.
Something like virtualenv should still be able to work as the executable remains in a trusted folder and it's just the libraries that remain in the users home folder, but having the libraries pre-installed would be easier than virtualenv.
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?
The same reasons that installing other applications into users home directories is not-ideal. Few people would consider installing an individual copy of an Office Suite or Web browser into each users home folder.
Some of the reasons:
The need to install for each user
Duplicate copies of the python code to setup and maintain
Additional disk space
Removing the separation of executable and data
Being able to run executables from users document folders.
There are perhaps certain circumstances where it may be advantages to install multiple versions of Python using home folders, but that should not be required for a standard programming class in a secondary school.
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?
We are not looking to create a new python install, but to create a way of installing libraries specifically chosen as useful for teaching programming.
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.
Any packaging and distribution system has challenges in terms of ease of install, ease of adding new packages to the repository etc. I don't see Python being any different from some of the other systems. I think the likes of PIP work well if you have admin privileges and a network connection, but in our cases we cannot rely on either. One of the things that makes education more difficult is that the developer computers are managed by a different IT group from the developers (teachers and students) that are using them. Stewart
On 19 May 2016 at 21:36, Stewart Watkiss <stewart@penguintutor.com> wrote:
We are not looking to create a new python install, but to create a way of installing libraries specifically chosen as useful for teaching programming.
Ok. This clearly defines the scope, which is helpful and will save time.
rgds Caleb
participants (2)
-
Caleb Hattingh -
Stewart Watkiss