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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
