 I don't know. At Flock, I tried to be creative with my talk name. It didn't work. Here I tried. A modularity of the program. Good afternoon, everybody. My name is Owen Taylor. My role at Red Hat is as the architect of the desktop group. I've been working on Linux desktop technology for maybe 20 years now. A lot of different things from text rendering to the GTK toolkit to GNOME shell and the system processor in GNOME. But this project, Purple Egg, which I'm going to present today, is a little bit different for me in that it's not looking not so much at the desktop itself, but how we can use the desktop as a place to start from and to integrate with when we're looking at a broad set of development on Linux and how we can improve using Linux, using Fedora, using GNOME as a place to do development in a broad sense. So I'll start off by telling you very briefly what Purple Egg is, and the way I would define it, it's project-specific, integrated, isolated environments integrated into the desktop. So I'm going to sort of structure this talk in two halves. The first half I'm going to tell you about project-specific, isolated environments. What they are, why you want them, and demonstrate how they're handled within Purple Egg, looking at the Purple Egg command line. And then I'll switch over and talk about how that integrates into desktop and the interesting things we can do given the basis of the project-specific, isolated environments. But also to tell you about Purple Egg is that it's a codename for a prototype. So it's, you can run the code now, and they'd be useful for some people. I'll tell you at the end of the talk how to go and get it as a flat pack. But it's not planned currently to be part of Fedora. It's really not part of a Red Hat product. And if it does become part of Fedora, a Red Hat product won't be called Purple Egg. That being said, I'm glad that we see we had special Purple Egg edition DevConf goodies this year. So as I've been said, I've been developing on Linux for 20 years. And for most of that, the story about developing on Linux has been pretty simple. Linux is a good development environment because it looks like your deployment environment. You can take all those server packages and install it onto your workstation. If you want to develop against Apache, if you want to use a whole bunch of Python libraries, the package, you just install them on your workstation and it looks like you have your server there. And then when you go to deploy, okay, your deployment is also going to be a Linux system. It's going to be similar to your workstation, but maybe it's a stable version of Linux. Maybe it's a little bit different version. It definitely doesn't have all your workstation packages. So that's the old model. Your workstation is your development environment and deployment is something else. That worked for a while, but people began to realize limitations. One of the big limitations is basically that you're dealing with very specific versions for your workstation, which might be, as I said, different from your deployment versions. So say I started developing up for Door 25, my application, and it used LibFu, a specific version that was whatever was on Door 25, version 1.2.3. And then for whatever reason, I decided to upgrade my workstation to Door 26. I want new stands of death house features, you know, something like that. And I started working on Project 2, the new version of LibFu, version 2.1.3. And my new applications were against the new version here. But someday somebody calls me up and says, hey, there's a bug in your old application, why don't you go fix it? So I switched back to my old application. I tried to run it, and I realized it doesn't even run on my workstation because I upgraded the library. So this is why you want project-specific development environments. If I'm working on a project, the only time that the library versions that I'm using for that project should change are when I say I'm ready to upgrade, I'm ready to develop the application against the new version. They shouldn't change because I wanted to run a new game on my desktop or because I just got held board one day and decided to upgrade it to Door 26. Another way of looking at why we want isolated environments is that we want a desktop operating system. It's not the same as what you want of an operating system that you're going to be developing against. For a desktop operating system, you want it to be stable. It's not going to be easy to use. You want to support your hardware, and more things, you want it to be tested as a whole. You want somebody else to say, it's running. I've tested it, and they can upgrade. I've tested those upgrades. So that's generally what you want for your desktop. You want it to be able to boot up every morning, check your mail, and then launch into your development environment. On the other hand, for the operating system that you're using as the target of your development, well, you want it to have a ton of software available so that if I wanted to use some component in my software, I can have it there. You want those components to be updated frequently. You want it to be very customizable. You want to say, I'm going to pick the set of software I want in my development environment. So, you know, of course, Fedora as a project is both things. We ship a workstation product, which we like to say has the attributes of a desktop operating system. It's well tested and stable, but we also ship a whole lot of packages that we want people to use as a development operating system, something to build their applications against. You know, this becomes the trends of Fedora, the trends generally in the industry are moving even more in this direction. We have a project called Fedora Atomic Workstation where the idea is that you ship the desktop operating system as an integrated test at whole and applications are a separate layer on top of that. It's actually, for Fedora Atomic Workstation, I can't even install a random package because it's actually not part of the core. Applications are a separate layer on top. And then we're making Fedora even more customizable. We're saying not only can you have all these packages with recent versions, you can have multiple versions of the same package and then we'll make that work out. So we're getting at this bare distinction there, and you really want to say that if I'm developing, I want an operating system specific for my development. So that probably sounds a lot to you like containers. That's how everybody does things nowadays. They have a workstation and they run containers on it, or they even have a VM and they run containers inside that VM. And the model generally people think about for containers is that your development environment is your deployment environment. So you can say I have developed and have tested it, and I'm going to take what I've developed and ship it over to the server I'm going to put onto the open internet and run it there. And that model, that development is exactly what you're deploying against, has some limitations or some problems to it. And I think those problems especially come when you're talking to a new developer. Somebody says, I want to run a web app, I hear Python is cool, what do I do? Because suddenly you're saying not only do you need to learn Python to get better at Python, not only do you need to learn about web frameworks, but you need to learn about Docker files and images and layers, and maybe somebody else is telling you that you need to learn about Kubernetes and pods or OpenShift and you can spend a year researching what technologies you should be using before you're ever swiping in the screen. So I don't think we can ever really say that these container technologies are what we want people to use from day one if they have no experience because they are simply too complex and even to start using those we have to try people a simple way through that complexity. It also is true that if I went to say after a little bit of research besides I wanted to use Django for my website in Python, and I went to the Django website, they have a nice tutorial, but the tutorial is not talking to you about how to do it in containers, it gives you some, you know, command line commands. So here it's how to set up the Django app, and here's how to run it, here's how to run some tests with it. So we also want an environment that is going to be very friendly to people who are looking at upstream documentation and figuring out how to do things and doesn't go off in its own direction, no matter how nice that direction is. The final sort of point I'll make is that, you know, one of the reasons we like building on Linux is that we have the command line. You can explore things, you can try out a little bit of something, you can, you know, try out a little bit of something else, you can see how things work interactively. But often with in containers, it's not that you can't go in and go into a container and run a shell there, but this is something that seems to be very much secondary. It's a way to debug things, it's sort of a crutch you can use if you can't get things to work out properly. But we want, generally, we want a way that the command line is actually very eccentric to your development. And this is even more the case when we're saying that we're going to make the host operating system about being a nice desktop, because then some things you might do on the command line in the host no longer make sense, you need to do it inside your development environment. So the purple egg model is that the workstation is different from your development environment, but that's not the same as your deployment environment. It might look a bit like your deployment environment, but it's specialized for interactive exploration and for being simple. So let me demo it. So, let me give you a bit of a degree. So one of the things about purple egg, it does, is it makes conventions. It's not ever going to say that you have to do something this way and only this way, but it tries to set out some conventions that are going to help you not have to make every choice once by once when you start using it. One of the questions it makes is that all your projects live in your projects directory and your home directory. So if I look here, here's some existing projects I have in my projects directory. And these are just basically, you know, what you might expect for a project. They are some source code and, you know, I don't have to get checked out. There might be something I just started creating locally. Here's about the simplest project you could have. It's just a whole Python, you know, that's all as simple as the project is you can have. But if you're a Python user, you see I also have a VMs directory there. And if you're a Python developer, you probably know what's in that VM directory. It's not the only way you can set up virtual environments, but some people, when they set up a virtual environment, create a VMs directory and put it there. So the thing is PurpleEye also understands that VMs directory and says, okay, you have a VMs directory here. This is probably a Python project in a virtual environment there. And when somebody wants to start working the project, they want to enter that virtual environment. Which, so what happens when I say, so it's like peg is the PurpleEye command line, shortened to be convenient from the command line. So if peg shell, it looks at the current directory, says okay, this is a project. It's a Python project. It has a VM directory. I'm going to enter that virtual environment. I'm going to change the command line to show that I'm in a project there and show these little square brackets that are convention to say it's PurpleEye and not just a standard command line. And in this case, that's basically all it does. You might just say it's a little shortcut to know how to enter Python environment, but it also knows that if this was a Node.js environment, it would know the right things to do to start working locally in a Node.js project and it could be extended to all the other different ways that people work on projects. But let's look at a slightly more complex example. I looked at, I said Node.js. This is Angular Phonecat, which is the tutorial from AngularJS, which is where the website is based upon Node.js. And there, again, if you're a Node.js developer, you see a Node modules directory and again, know that's where local stuff is stored and you know that you might have to enter, put the .bin under that directory into your path to run things that have been installed locally. But there's also a file in here called peg.yaml and let's look at the peg.yaml, the very simple file. And peg.yaml is where you store stuff for purple egg where it can't get from the environment. So it says that I want a local environment, which is based upon Fedora24, in addition to the standard packages from the Fedora24 base image. I want to add Node.js. Just when I, now when I run peg.shell here, I see a bunch of output from Docker and then I get back and get a similar double angle bracket id prompt. So it's what went on here. In this case, purple egg looked the peg part of it, looked at that peg.yaml, said, I need to create a Docker file. I need to have a file that's going to define how my local environment is defined. I'm going to create a Docker file. I'm going to build a Docker image out of it. It was cached here, so that was why it was very fast. And then I'm going to go into the, run that Docker image and mount the project directory in the Docker image and then you have your project-specific isolated environment. So if I list all the packages and count how many lines there, I see that there are 220 packages installed. This is question in the back. The project directory is, so the question was if I change something inside the environment, does it come back to outside? And yes, it's not, a copy hasn't been made into the environment. It actually mounted the directory into the environment there. So, whether I'm working in the directory inside the environment or the outside environment, it's in many ways fairly invisible. And sometimes you can do some things outside and some things inside. So the environment has, as I said, has 200 packages here, which is a lot less than I have in my workstation. And if I look at it, I see that I'm actually in slash projects. So that's where purple egg mounts things inside the isolated environment. But I could, but if I ran npm start, it would give me a message, okay, that I started up the web server. I'm running on this local port here. And I could open that. And then I'd see my AngularJS example application running on my browser there. And if you're paying careful attention, you'll notice that it's running on local host and we're on the same port. And this is one of the things that purple egg is doing for simplification. Often you have your Docker containers have a separate networking setup and you have to basically bridge between that and the host networking setup. In this case, the standard default purple egg configuration is that the, to share networking so that the application runs with the same local networking and any ports the application opens are immediately available to local host. Just trying to keep things simple is often what we're trying to do here. So I'll get out of there. Then I want to show you one more thing about purple egg. And that it has a facility for creating new projects for using a template to start a project. Do the peg create Django my Django project. Again, we see a bunch of Docker output. Then we see some more output as I'm setting up the project within the isolated environment. And then it finished. Now I have a new project called my Django project. So I go back to my projects directory and list it. I can see that it's now there. And I look at it and I see that I have centered boilerplate that every initially created Django project has. I have the VMs directory for local Python environment. And I have a peg.yaml. So basically I did the work that needed to set this up. Templates in purple egg are currently extremely demo aware. So I'm not going to say there's a whole lot there but this is the only template but it basically shows how they work. And the idea is to try to get people going with a standard setup very quickly but not to go that far beyond that because you don't want to create tons and tons of purple egg specific stuff that's not going to make sense to somebody who is looking at an upstream tutorial. And then again if I ran again you run peg shell to go into this project and then they run the server and I would see the Django hello message. That's very similar to what I showed you with Node.js. So that's sort of giving you a flavor of peg the command line. And while some think of a simplified here, there's still obviously a lot of navigation around in the command line knowing what things to use knowing the options to peg. And it's certainly not entirely friendly to a new user. It's also not taking things very far ahead for the experienced user because we're still in this world where we give you a terminal and we say figure out what to do in the terminal. We're not actually integrating that into the desktop. We'll go back to the presentation here. So the typical worldview of development is that either you have an integrated environment, an IDE or you have a terminal. IDEs have a whole lot of user interface. They have all these dialogs to configure your project. They have views and they're definitely GUIs. Terminals we usually think are not GUIs. They're the opposite of GUIs. They're terminals. And you might be running a terminal within a desktop but it doesn't really integrate with the desktop in any meaningful way. You can cut and paste from it somewhere else. So purple egg in some sense it meant to sit in between. It's definitely a terminal. It very much emphasizes a terminal based workflow. But it's also embraces being a user interface and being integrated with the desktop. And the kind of things I've shown you with purple egg are actually how we do that. The problem generally trying to make a nice interface for terminal development is that we don't really have any idea what's going on. We say the user is using a terminal but they can do one of a million things. But with purple egg we've established some conventions. We've said that your projects are stored in the project subject of your home directory. We've said that you enter your project by doing working on it by doing peg shell and we've just added a little bit of glue there that allows us to make some sense of it. Let's look at purple egg. In good home shell in the good home environment when you want to do something one of the common ways you do that is you go to the overview and search. I want to go back to working on the Django project I created. And I remember to call it my Django project. I start typing my Django project and I see a search result from the desktop saying you have a project there called Django project. Then I can click on that and then immediately a terminal opened up which is all set up to work on that project that was already working on it. I didn't have to remember where was it how do I start working on it that all was taken care of for you. We have this thing in Linux where we often try to pack stuff into the prompt. You put your working directory, your Git status and all that. And if you set up enough stuff you can have very little space to actually type in the command line. So the idea here is that we're going to take some of that stuff and put it up into the title bar and out of your working area. This thing here is just saying that there's one tab open. I couldn't create more tabs there and that's just giving me, I can do all one or all two to switch between them. I could do the same things that I was doing elsewhere. Here I could do this as I did before I could run server, it would be available. So that's the very basics of purple lag is it's a terminal that gives you all your project and it sort of gives you a place to go to your project and it knows how to set it up. But there's also some other things nice that we can do. So say, let me make the font bigger so I can do the same thing. So I wanted to initialize Git for my project. I wanted to put it into version control. Git init would be how you start then. Let's add some of the files here. Then I see something else pop up into the title bear there. So purple egg was watching the directory there and said, oh, this is a good project. Let me show you your active branch there. And if I switch branch if I create a new branch it will follow that and I can use this control to switch between the branches. You can imagine setting this to show other information there that's contextually relevant. Do you have any files that you haven't committed or that could be extended there. You could also go in directions that are not involving Git necessarily. You could have controls there to launch the web server or if you have other containers to launch container. So that's an ability because we understand what the project is and we know some of the conventions there can add a little bit more information as we need it. We can start creating user interface that enhances the terminal experience without replacing the terminal experience. Of course, that's art if you already have the this is when you can already have the project going. So I think that's the question would be how do you how does this handle the initial case. And that's something I don't have fully worked out here but I just run purple egg. What you do is that it lists two projects and let's pick one of those. And then if you had a new project there the idea is that your templating wizarding would go here. So this is just a bit of UI stole from Good Own Builder. It's not hooked up to anything. But it would go ahead and run the same things that happened when you did peg create. Create something for a template there. So that's the very thing. The goal here is that it has a dual nature. One thing that's going to be useful for beginners both because it provides a simplified view of containers, a simplified view of how I can start going with things. But it's also meant if you're only useful for beginners then it's not that useful because it doesn't keep in people's workflow. They say well you know I can I can start with it but then what do I do afterwards. To make something truly successful to make it part of the ecosystem you actually have to make it useful for advanced users. And the way that PurpleEye does that is it well it gives you some organization to how you're working with things on your desktop. You no longer have a genetic gang pile of tabs. You have windows for specific projects. It gives you integration to the desktop things like search and it allows you to quickly navigate between different projects. And then also it has these user interface features like showing you your get branch or your get status. So that's the case where we're trying to make things better for somebody who's actually working on a project and using it day to day. If you are a developer as you've been following along here you probably have one of possibly three actions. One is that this looks really useful to me when can I have it. Or more likely it's like well that looks useful but I've already solved a lot of these projects problems already in some other different way. Because of course we haven't had this so you've had people to come up with their own ways of doing these things. And sometimes they're painful but you have them working. But the third reaction you can definitely have is this doesn't look at all relevant to what I'm doing. So to sort of explain how PurpleEye fits in I think we have to look a little bit at the types of development. If you're developing a server application you're eventually going to deploy via containers then that's really in the core target of PurpleEye. It's also the case if you're developing a library. Another place where PurpleEye can fit in very well is if you're doing casual computing. You have a bunch of data you want to write some Python scripts to manipulate it. But if I'm doing mobile development then I probably have an IDE for that that already has its own idea of an isolated environment. If I'm doing graphical application development well then I want to do something that's more specific to that. And using some of the same concepts but in a different way we've been working on that with flat pack in the GNOME space. And then the thing I don't even mention here is that if you're doing operating system development if you want to actually change how the operating system is constructed, if you want to hack on the desktop or you want to hack on the boot loader or the kernel then this is not relevant to you at all. In that case you probably want to be developing in a virtual machine or your development environment because need will change everything and this is just a container running within your workstation. So where can you go from here? Well one direction is simply that expand whether it's there now you know finish the templating add more tweaks to the terminal add new types of integration there you know possibly it should have some features that advanced terminals have like split screen that's one place that it could go. And there's also the idea that the templating does need to become more extended as well. I shouldn't have a million templates but it should have templates for all the common languages and development environments. A different way is that PurpleEye would have to develop is figuring out what to do and you don't just want one container that you type command line commands in. When you're starting to do more sophisticated applications then maybe you want to need a MariaDB instance, maybe you need a Redis instance to do caching, maybe you need something else like that with the service running there. So how do you make a service available there? And that's you know currently a lot of people use Docker compose for that. You're saying well here's the three containers I need to run an application. Start them from me, here's how they link together. And definitely peg.yaml could be extended to some of the same things but probably the way that's more consistent with the ideas of PurpleEye is it actually should just understand a Docker compose YAML file and say well if I have a Docker compose file here then I can use this to launch the components that are needed for the application environment there. I can maybe have the controls to start and stop those containers and control their status. So that's sort of the PurpleEye way to do it to say let's embrace that rather than let's create a new different way. But there are advantages and disadvantages either way so maybe it could be more targeted toward PurpleEye. And then sort of a final important thing that you have to address to make PurpleEye more useful is how do you get the user from deployment. So I said that in day one you don't want to be in the throw somebody into the full world of OpenShift or Kubernetes or anything like that because there's just too much complexity there. But on the other hand once somebody has fired up the editor and written a cool Python website until they get it deployed somewhere they haven't actually achieved anything. They've had a cool API on their computer that they can show the laptop to their friends with. So one of the things that PurpleEye probably needs is a way to say okay we have a local application going here's how to throw it into source to image and bring it to OpenShift or here's how to take it to a different deployment environment. So that should be part of PurpleEye as well. So that's basically what I want to present here. If you go to the GitHub page for PurpleEye there's instructions how to install it. It's a one line command on Fedora 25 and then there's contact me probably the best place you can find me on IRC on FreeNode and Fedora Workstation and give ideas for how this should be going. So I guess I'll take questions now. So Matt. Yeah, so maybe I missed this. How do I get utility software into, or we know compilers that are into the container when I do a peg shell? Okay, so yeah, so the pattern might be one thing, but another example is like I love the text editor Joe. I do not expect Joe to be installed on Fedora Atomic Workstation. How do I make sure that it's available in my projects? So if I said this file pegged up, yeah well the question was how do I get more software into my containers there? And the simplest answer to this is that this file pegged up, Amel says here are the software I need for my project, so you can just add more things in there. This is where a compiler would go. I think if you start saying that I have some personal things I want to be installed in every environment then that would probably belong in some sort of configuration file for PurpleEye because Yeah, it's definitely an RFP. You know right now there's some standard things that probably push into every environment. For instance it puts less in because less is not part of a Fedora base image But Yeah, I mean because it's not needed if you're running a server software, but if you're actually working interactively inside you want less. So, you know that's probably a set of software that should be configurable for the user. Okay Other questions? Okay, go ahead. Another feature that so I was talking to some of the bread and developer experiences from what it's like from an operating system made for developers and the thing that I was super excited about was snapshotting so a feature to snapshot your container like outside of the gate basically I would like to be able to accidentally screw up my entire environment and say oops put it back with containers possibly there's some way to do that I don't know how you do it but it would be a very valuable feature so so the suggestion was that what developers want is that if they screw up their entire environment they have some way to roll back and fix it in some ways I think purple like is actually an alternative solution to that because we're saying don't mess with my operating system do it inside a container and make that nice so hopefully we're creating less problems where you say I need to install this new version of Python project package and then suddenly your yum doesn't work anymore but second thing is that hopefully eventually you take your peg.yaml and you start putting into version control and then but I think I guess I could see that beyond that especially if we start really looking more in the direction of like those interactively modify the containers then it could definitely be nice to be able to snapshot them okay does your terminal show the good integration does it work for any good project or does it have a peg.yaml? no I mean what as I said that peg tries to figure out what's appropriate and it actually if there's nothing no peg.yaml no virtual environment there it'll just drop you into a plain shell there so as long as it's in the projects you can run purple like there and it'll have that good integration okay well thanks everybody it is in the same space I mean I think it's sometimes trying to concentrate a bit more on the experience after we got started because I think if that was this in its light it didn't really engage you you said okay I could get started but I wouldn't keep on using it I mean if you've got a better idea that would be fine but if you don't let's do that definitely an idea yeah just looks really interesting I think we're about to give a talk about all the things I'm sharing as a particular trip is how to run a Python editor as a local command line interpreter which has issues there's a lot of things you've already solved in here and one of my partner projects during my talk are you ready for more people to hear about it? happy people to hear about it it's like they don't think it's finished but yeah I mean at the very least it solves the very simple issue of data scientists need to use these specialized containers yeah so I've now been launching as a command line in a security say scikit Python yeah and that's a pretty good direction for some of the stuff I'll be talking about so I will be throwing it up to you thank you it's not at all fedora-specific the only thing that's fedora-specific about it is that the probably tenor templates that we ship are probably full fedora as the container environment but you can definitely use any docker in an integrated image depending on anything that's fedora-specific so yeah I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I