nthiery
commented
8 years ago @embray: do you have experience with this kind of installer? If yes, this would be a nice standalone warmup project that does not require much insider knowledge of Sage.
Closed nthiery closed 6 years ago
nthiery
commented
8 years ago @embray: do you have experience with this kind of installer? If yes, this would be a nice standalone warmup project that does not require much insider knowledge of Sage.
embray
commented
8 years ago A little bit, though it's been a while since I built a Windows installation package from scratch. Mostly sounds pretty reasonable though.
One one hand, I'd rather spend more time directly addressing the issues on Sage and its dependencies. On the other hand this would almost certainly take less time and would be a very serviceable stop-gap measure if it works--I think much better than using a full VM.
embray
commented
8 years ago What is the difference between sagemath-jupyter and sagemath-fat-jupyter? Does the latter just include more dependencies?
(One thing I've been wondering about but haven't had a chance to fully investigate yet is how well Sage manages with missing dependencies. Do most features still work if some optional dependency is missing?)
nthiery
commented
8 years ago On Fri, Jan 22, 2016 at 08:24:37AM -0800, Erik Bray wrote:
A little bit, though it's been a while since I built a Windows installation package from scratch. Mostly sounds pretty reasonable though.
Sounds good, please go for it then :-) Any rough estimation of the amount of time this would take you?
One one hand, I'd rather spend more time directly addressing the issues on Sage and its dependencies. On the other hand this would probably take less time and would be a very serviceable stop-gap measure if it works--I think much better than using a full VM.
Yes, for the long run a real solution addressing directly the issues and Sage and its dependencies is desirable. Here it's about picking a low hanging fruit with potentially high short term outcome. And learning more about what this kind of technology can bring us.
Cheers,
Nicolas M. Thiéry "Isil" nthiery@users.sf.net http://Nicolas.Thiery.name/
nthiery
commented
8 years ago On Fri, Jan 22, 2016 at 08:26:39AM -0800, Erik Bray wrote:
What is the difference between sagemath-jupyter and sagemath-fat-jupyter? Does the latter just include more dependencies?
Yes, that's indeed the plan. We haven't yet starting building the fat jupyter though. Typically it will contain latex & more software and database that Sage knows how to use.
(One thing I've been wondering about but haven't had a chance to fully investigate yet is how well Sage manages with missing dependencies. Do most features still work if some optional dependency is missing?)
You can get a feeling of this by a:
grep -r "# optional" src/sage/in the Sage directory. This will give you all the tests that are flagged as optional because they require some optional package or other dependency (like internet!).
Cheers, Nicolas
nthiery
commented
8 years ago For whatever it's worth, some potentially relevant stuff
embray
commented
8 years ago Good news and bad news on the issue of home directory mounting:
The good news is that the boot2docker Linux has done a little bit of the legwork for us, albeit a bit flakily. Currently it is set up by default to automatically mount the C:\Users directory to /c/Users in the VM. So users, in turn, can launch a docker container that mounts /c/Users as a volume (which can also be done automatically by a launcher of some sort).
The bad news is that this currently only works, out of the box, for C:\Users. It is possible (via a script or whatever) to programatically add additional share folders to the VirtualBox VM like so:
/C/Program\ Files/Oracle/VirtualBox/VBoxManage.exe sharedfolder add default --hostpath <host OS directory we would like to mount> --name <name to use in the Linux VM> --automountHowever, this currently has a limitation. Despite the --automount flag it does not actually automatically mount in the case of the boot2docker Linux. I don't know the full history behind this, but this comment sheds some light:
In short, it seems there's some incompatibility with the VBoxService, which handles auto-mounting, depending on the host OS's machine architecture.
This is not a huge deal though. For now we can get pretty far with just the user's home directory. If we did want to later make it possible for users to access other directories from within Sage (i.e. within the container sage is running in) our launcher script can still created the shared folder in the VM, as in above, and then mount it by running
docker-machine ssh default mount -t vboxsf -o uid=1000,gid=50 <host OS dir> <guest OS mount point>The other downside I found, specifically thanks to running in French Windows, is that there are a few annoyances related to listing contents of the users's home directory once in the docker container. For example (with /C/Users/embray mounted as a volume in a container as /home/embray):
root@72f037dbbe11:/# ls /home/embray/
ls: cannot read symbolic link /home/embray/Application Data: Protocol error
ls: cannot read symbolic link /home/embray/Cookies: Protocol error
ls: cannot read symbolic link /home/embray/Local Settings: Protocol error
ls: cannot read symbolic link /home/embray/Menu Dmarrer: Protocol error
ls: cannot read symbolic link /home/embray/Mes documents: Protocol error
ls: cannot read symbolic link /home/embray/Modles: Protocol error
ls: cannot read symbolic link /home/embray/Recent: Protocol error
ls: cannot read symbolic link /home/embray/SendTo: Protocol error
ls: cannot read symbolic link /home/embray/Voisinage d'impression: Protocol error
ls: cannot read symbolic link /home/embray/Voisinage rseau: Protocol error
AppData Menu D??marrer Saved Games
Application Data Mes documents Searches
Contacts Mod??les SendTo
Cookies Music Videos
Desktop NTUSER.DAT Voisinage d'impression
Documents NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}.TM.blf Voisinage r??seau
Downloads NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}.TMContainer00000000000000000001.regtrans-ms ntuser.dat.LOG1
Favorites NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}.TMContainer00000000000000000002.regtrans-ms ntuser.dat.LOG2
Links Pictures ntuser.ini
Local Settings RecentThere are of course two problems here. The first being the complaint from ls about being unable to read symbolic links. I'm not sure there's much we can do about this--the paths in question are actually junctions which can't be followed by the virtualbox fs. This isn't such a problem, it's just annoying.
The other obvious problem, which is more problematic, is the mojibake in non-ASCII characters. I'm still trying to find out what's going on there exactly.
embray
commented
8 years ago Some discussion about the non-ASCII issue here: docker/machine#1763.
Okay, so it seems from the VirtualBox end of things it's converting the filenames to UTF-8, so Linux only sees UTF-8. Great. (And in fact when I log into the VM it displays them correctly). However, from within the container they are not correctly displayed still. My guess is it's just a problem with the Windows cmd terminal.
embray
commented
8 years ago Unfortunately I haven't been able to get very far with this. Will revisit later.
embray
commented
8 years ago Interestingly, on the unicode issue, if I log into the boot2docker VM with docker-machine ssh and list that same directory I don't get the "protocol errors" from ls, and I do see non-ASCII characters displayed properly (the folder is mounted with iocharset=utf8).
However, when I start the docker container and list the same directory from it I get errors from ls for the junctions, and non-ASCII characters are not displayed. So it seems to me the bug is possibly with the bind-mount of this directory within the container. Anyways that's all I have for now, if someone wants to spend more time investigating this. But actually, no, I don't think this has to do with the filesystem, because when I'm in the container unicode characters simply aren't printed at all, such as if I try to print on in Python).
embray
commented
8 years ago I've created a repository for the Windows installer here: https://github.com/embray/sage-windows
It's a fork of the docker/toolbox repo which is my starting point. For now just focusing on Windows but most of the work wouldn't be too hard to transfer over to OSX if we wanted to. Since I don't know if it's terribly necessary though we could just delete the OSX parts later. Also if this work is successful we can transfer ownership of this repo to the sagemath org. I've included an issue tracker on it so I can track issues specific to sage+docker on WIndows there.
nthiery
commented
6 years ago I guess the work here is superseded by the cygwin installer. Thus closing the issue.
Create a windows installer for newbie users that:
Bonuses:
Goal: experiment with the technology, and compare how much ressources (disk/ram size/startup time/...) this uses w.r.t. our current virtual box machine. If this compares nicely this could become a replacement for it.