ActiveState Platform Demo: Automatically Build Language Distros
- Automatically build open source language distributions and runtimes
- Automatically resolve all open source dependencies
- Automatically package open source distributions for any platform
Learn more about the ActiveState Platform for Open Source Languages.
One of the most exciting features of the ActiveState Platform is the ability to automatically create a distribution of an open-source programming language that’s tailored for your project’s needs. Because the platform automates the process, there’s no more wrestling with dependencies, patching outdated libraries, or debugging builds. All you really need to do is just select a language, the packages you want, and the output format, and let the platform do the rest. So let’s take a closer look at what the platform can do for you.
As you can see, I’m logged into the ActiveState organization on the platform. They’ve already got a bunch of builds that we call “Projects.” Now, I can create a new project, or I can just select one of the projects from the list here. Let’s go ahead and choose the new project. I have a lot of options for this build, starting with the language itself. When I click on “Edit”, I pull up a window that shows me the language choices I have. Currently, this build is for Python 3.6.6, but I could choose an older version like 2.7, or the latest, 3.7.1. Now, if I wanted to make this into a multilingual build – for example, my application requires both Perl and Python – I can add Perl to this build and just choose one from the list, say Perl 5.2.6. I’m going to stick with just the recommended Python 3.6.6 in this case.
Now, the other thing I can do is choose my output platform. When I click on “Edit” you can see that I’ve got a number of choices when it comes to Linux platforms. I’m going to stick with the recommended Centos6, but I can also output this build for other operating systems as well. For example, I could output to Mac or I could output to a Windows 7 platform as well. That’s in case I have a development team that’s working on multiple platforms with the development environment, so I can create one build for multiple platforms.
Then finally, I’ve got a list of packages here. Now, I’m creating a basic web application, so I’ve got a lot of the Flask packages added here, and a few others. What we can see down below is that all the packages I’ve selected have dependencies, and these dependencies are automatically pulled in. In fact, let’s take a look at how that works.
You can see dependencies – 45 of them right now – but I can see a package that I typically add to my web applications that’s missing right now, so let’s go ahead and add that package. Then you can see in my list of available packages, I have 425 of them. That’s because we’re pulling this directly from PyPI and we’re looking at packages that we’ve vetted and know are good, well-supported packages. I’m going to go ahead and search for the one I want, which is associated with PyTest, it’s just the coverage package. Then when I click that to add it, and then click “Done”, I’m going to have another package added in, and I see that my dependencies have moved to 47. What’s automatically happened behind the scenes is that a piece of functionality called the resolver has found the dependencies associated with PyTest Coverage and automatically pulled those in. Now, if there are any conflicts between any of these dependencies that resolve, our functionality will automatically resolve them for you, so there’s no more need for you to manually get involved and resolve any of those conflicts yourself.
So with this done, all I need to do is just commit my changes and click “Builds” to kick it off. Now, builds can take anywhere up to the better part of an hour to run, so while we’re waiting for that to happen, I’ll just point out the fact that we track all of your commits and allow you to revert to any of them. That means you can go back to any legacy build you might have with legacy older packages and older dependencies, effectively providing you with build pinning .You can also fork the project – in other words, you can create a new one based on the new project. Maybe you want to strip out the test harnesses and make a version that’s better suited for production. You can go ahead and do that here, and we’ll auto-track that original, so any updates you make to the original project will be reflected in your production-ready version.
Now, that build is going to take a while, so let’s go ahead and move back to our list here. Maybe we’ll find one that’s already been built for us, say, TheHomeRepot. Now if I click on “Builds”, it’s already been built, so you can see that there’s a number of artifacts that I can download. The last one down the line here is my Tarball for my Linux platform. I can go ahead and download that and set that up on my machine and start coding in Python right away.
So as you can see, with just a few clicks you can create, in about an hour, the kind of open-source language distribution that typically takes a team of build engineers days or even weeks to accomplish. As we get more packages added and more packages successfully built for your platform, those build times are going to decrease, all of which means that you’re going to spend less time building your open-source language and more time coding in it.
