[sugar] Development environment for newcomers

[Ian Bicking]

At PyCon a few of us looked at the development environment and how 
newcomers could work on it (the people involved where: Michael Fletcher, 
John Hall, Brian Dorsey, and Jeff Younker and Frank Wilder for a short 
while).  I've put this off a bit, but I wanted to write up our thoughts 
(unfortunately we didn't have real conclusions).

Goal
----

My personal goal is to be able to run a coding sprint, where people can 
show up and we give them CDs, USB sticks, etc., and they can get a 
running environment that they can develop on in a reasonable amount of 
time (half hour or so).  I expect a variety of computers, and I don't 
want to depend on them having anything specific setup.

When I've done this in the past with professional programmers using 
software that is reasonably simple to setup, it can still be very hard. 
  I'd like it to be simpler than that, and right now it is much more 
difficult.

I also want to setup a development environment people can use.  There's 
a lot of things to learn at once, so I'd rather people just be able to 
use an editor they are familiar with, and other tools they know 
something about.  Minimizing the number of novel things people have to 
deal with will allow them to actually pay attention to the important 
stuff (like writing code).

Ideas
-----

I think sugar-jhbuild is pretty much right out; even if it was made 
perfect and totally self contained, I can't see people reasonably 
running it ahead of time, and it certainly takes too long to do at the 
sprint.  One idea Michael has been working on is to do a complete build 
in a virtual environment, and then people can use that environment; 
either with something like VMWare, or potentially produce a live CD.  I 
don't think the CD that is produced from the builds really makes sense 
-- doing stuff like hardware detection is really out of the scope of 
what OLPC should be concerned with.  But if we can setup all the 
dependencies on something suited for a live CD, and install and 
pre-build parts for that CD, maybe that would be workable.  That still 
won't give people the environment they are used to, unless they happen 
to be used to what we produce.  (I think Michael is using Ubuntu?)

I'm more positive about emulation, as it's fairly reliable; i.e., qemu 
or the VMWare player.  You could a hosted/sugar-jhbuild environment, or 
the actual build image.  If you do a sugar-jhbuild environment, 
presumably people will use that environment for all their development, 
using whatever tools we put on there.  They'll inherit any network 
settings and hardware support.  Performance is a little slow; realistic 
for actually running the environment, somewhat tedious (but not 
unacceptable) when running development tools.

(Note: one issue with VMWare emulation is that currently networking 
doesn't work because of a missing driver, as noted here: 
http://dev.laptop.org/ticket/925)

Another option is using the builds themselves.  The builds and the OLPC 
environment really isn't suited yet to doing development.  I don't think 
that should be a blocker for people either (I'm not a big fan of eating 
your own dog food, at least not until much later in the process than we 
currently are).

One of the more hopeful options seems to be some kind of network drive, 
so you can edit files from the host environment.  All testing would 
occur on the emulated image.  Either the host or the image could have 
the server, with different tradeoffs.

sshfs was suggested.  This is fairly difficult to setup on host 
computers, and while something like Nautilus might be easy to setup, 
many other tools won't work well.  Another issue is that the host 
computer has to see the image on the network.  I haven't tried VMWare; I 
get the impression it's fairly easy to set this up there.  Setting this 
up under qemu is much harder, and it's not clear to me if it's 
reasonable at all under Windows.  I'd really like this to be workable 
for Windows users.  Of course, if the host can see the image there's no 
reason we could have many server options, including Samba and NFS in 
addition to ssh (all of which may not be part of the standard builds, 
but seems easy enough to add to a custom build).

Setting up a server on the host computer has its own issues, though it 
can be potentially easier -- servers require relatively little OS 
integration compared to a client.  In that case, the host would run some 
server (NFS, ideally SMB could work), and the image would mount it. 
This avoids the emulation networking issues, but then we have to 
consider where to mount the share... can we overlay the entire filesystem?

Disk space on the image is a problem.  It would be nice if people 
weren't constrained to 512Mb, so they could play around with larger 
things, even if those things can't be deployed in that form.  It may not 
be an issue if all the development tools stay on the host system; but I 
don't think gcc will work well on the host system, as it's not the 
image's native gcc.  Installing development libraries take a lot of 
space.  OTOH, I'm much more interested in getting people writing Python 
code.  But it would be nice if there was at least some story for how 
people could develop bits of C code (or Pyrex) if there are particular 
performance benefits in their application.

Sorry if this wanders, I've tried to include at least some of the bad 
directions and possible good directions and caveats in this, and the 
result is scattered.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org