Dustin, that's great feedback! I essentially think we need to work on two fronts: - we should make the less-than-ideal docker approach more comfortable - we should make it easier to do host -> target development
On Wed, Jun 24, 2015 at 3:47 PM, Dustin Kirkland <[email protected]> wrote: > On Mon, Jun 22, 2015 at 5:23 AM, Oliver Grawert <[email protected]> wrote: > > hi, > > Am Montag, den 22.06.2015, 17:59 +0800 schrieb YC Cheng: > >> Hi, I feel uncomfortable with sentences like > >> > >> > >> "Development isn’t done on the system anymore, instead the Snappy > >> system is a target system and you develop from your Ubuntu Desktop > >> host system" > >> > >> > >> I guess you are not rule out the possibility to do development on the > >> target. You just propose it might make more sense to do that on Host > >> system, right ? > >> > >> > >> From what we think about Phone Desktop system, we feel the phone is > >> getting more and more powerful, so that it make sense to use Phone as > >> Desktop system. If that's the case, I think it also make sense to do > >> development on the Phone / target. > >> > > dpkg and apt are currently disabled and will soon be completely gone > > from the core image (as will python and probably even bash at some > > point), you can indeed remount / to work on files in core in case you do > > any kind of implementation on that level... > > > > but i think having a snap with lxc container or chroot that ships a > > development environment to work in is the better idea here and saves > > normal developers from having to taint their system. the touch UI will > > be one or a number of snaps on top of core (or replacing core), i think > > we should offer *-dev-env,snap packages for each of these that come with > > all tools and the source for that specific snap inside so you can > > locally build, change, debug and install it (perhaps with an easy snappy > > command) > > > > the good thing about moving this bit into the snap area is that you can > > do A - B comparisons by rolling back and forth between the two snap > > packages for debugging ... > > > > also the desktop will become snappy too in the snappy personal world. > > you could use these development snaps from there to have your changes > > installed via snappy-remote after building them (and as cherry on top > > such a snap could provide an interface to the SDK for building and > > debugging stuff) > > > > all this is slightly off-topic for the comfy discussion though which is > > more about enhancing the core image by some extra commands to make our > > lives more comfortable, i think the development environment for > > snappy-personal deserves its own discussion ... > > Thanks for the tremendous amount of detail here, Loic! > > I tend to agree with Ogra -- I think we'd benefit from separating the > discussion into the (a) dev-environment discussion, and the (b) > comfy-environment discussion, as I think they're distinctly different. > > We absolutely do need to refine the developer environment experience, > for all or the reasons Loic mentioned, but I think these can be > cleanly addressed with or without comfy. > > Comfy is concept that I feel strongly about. Without a comfortable > experience, the first-use experience around Snappy feels a bit > shallow. I've sat down with dozens (hundreds?) of Ubuntu faithful, > using Snappy for the first time at various events around the world. > And just about every time, 5 minutes in, there isn't much else they > can do with the system. They try to run git to grab their code from > github. Command not found. They try to run wget to pull a tarball > from somewhere that they've stashed it. Command not found. Curl. > Tmux. Gcc. Strace. Ditto. I've actually shown multiple people how > to send/receive data using nc (netcat) on a snappy system. > > Snappy is great, once the appliance has been built with apps > pre-installed on the system, and we're working with some excellent > partners to bring that vision to life! But take a Raspberry Pi 2 with > nothing but Snappy on it, and it doesn't yet feel like the rich, > vibrant Ubuntu ecosystem that the world has come to love. > > Of course we all understand why git/wget/curl/gcc won't be in the > minimal Ubuntu Core -- I certainly don't disagree with that. But some > way of obtaining the familiar tools that makes a Snappy familiar and > usable as something more than firmware is critical for adoption. > > ChromeOS is pretty cool, from this perspective. For most users, a > Chromebook is just a web browser, and they love it for that. But most > Chromebooks have a simple, unobtrusive way to put that machine into a > developer mode, dropping to a shell and obtaining utilities that > exercise the machine much more like a general purpose Linux OS. > > So far, my less-than-ideal workaround on Snappy has been to 'sudo > docker run -it ubuntu', drop into a comfortable Ubuntu-ish root > filesystem, apt-get what I need into that environment, and use it > there inside of the Docker container. Sometimes, I actually need > those tools outside of the Docker container and onto the host. This > is where I've had some success copying files/binaries out of the > container. It would be grand if that process could be backgrounded > and automated somehow... > > Cheers, > Dustin > > -- > snappy-devel mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snappy-devel >
-- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
