Presenter: Kevin Griffin of SwiftKick Training, and an Inedo-certified Master Trainer
A package, for all intensive purposes, is what we call a container file. Think about it the same way as a zip file. A container file is just a file, that contains other files. So those might be binaries, source code or scripts, and then there’s also a manifest that tells you what all this stuff actually means.
We use packages to deploy code dependencies to different projects, or to install external tooling. It doesn’t really matter what you use the package for, a package is just a collection of things that you need to use. It also provides you a means to install and update them in a meaningful way.
If you’re a library- or a tool-creator, packages really help you with distribution. If I’m creating a tool that needs to go count the number of files in a directory, it’s a simple tool, so I can put it up on a webpage and just tell people to go download it. Or, I could create a package, I could put that package up in some sort of central repository, or central feed, and I can tell people to go there and download it. No one thinks it updates, but it really helps with discovery.
Say someone is looking for a file counting utility, as an example, and is searching for a tool that meets that need. They’re probably going to go and type “file counter” or “file counting utility” and if you have a package sitting there, that solves that need, you’ll pop up in their search results and they can go download your tool.
Now there’s a couple different types of packages, I tend to talk about packages more from a software development standpoint, and that’s just because I’m a software developer at heart, but that doesn’t mean that software developers are the only ones that can really take advantage of packages.
There’s fundamentally three types of packages. Developer packages, application/component packages and what we call machine packages.
Developer packages are probably the most commonly used and it’s what I see the most out there in the industry. These are used by software developers to put out different types of dependencies. It doesn’t matter if it’s open source, or if it’s some component manufacturer.
I do a lot in the .NET environment, and we use a library called JSON.NET. It’s one of the most popular packages in the .NET ecosystem, and we use that for json manipulation. Everyone goes and gets that package, we all just know that’s a thing we have to go get. All these different packages have their own package managers to go with them.
These are things that you might use internally that aren’t necessarily available for public consumption. I’m not going to go to a NuGet feed and pull down your internal packages because that’s not stuff you want to put out into the public.
This is where UPack really fits into ecosystems. You have stuff that doesn’t fit into the mold of other packaging systems, but you still want to package them up and make them available to the rest of your team.
These are tools and utilities that mostly system administrators might use. Developers use them as well, but if you’ve ever done anything with PowerShell, you would probably use Chocolatey. If you’re a linux-based administrator, you’d use appget or rpm.
If I want a utility that tells me the IP address of my machine, that’s just a package that you install. If I want to search through all the files on my file system for a keyword, that’s just a package that you install. Everything’s a package.
These aren’t just tools that you install and run on the command-line. We need to think about packages in a bit of a broader sense. Anyone out there that has a smart device, whether it’s IOS or Android, has installed applications from an app store. Well an app store app is just a package! You’re installing a single file, with a collection of binaries and different metadata inside of it, and then once it’s installed, you can use it.
Machine packages really solve a fundamental problem: how do we quickly and efficiently install software and utilities
Like I mentioned before, it’s more than just the installation, it’s about the maintenance and maybe the eventual removal of the package as well.
If I install a windows application, that windows application puts files in a directory, edits my registry, and puts stuff into a systems folder. Well, what’s going to track the changes that installer made? Because that application is not self-contained, it’s difficult to go back and clean up after it.
Anyone who’s done windows administration knows, if you remove a complicated app, the files might be gone, and some of the registry keys might be gone, but if you really want to go back and clean up the system, you have to go through a lot of manual steps. You have to manually find registry keys that got created, remove those. Go look for any external files that might have been created during the lifespan of the app, delete those. It’s just a headache to do all this cleanup. If we think of applications in more of a package sense, deleting the package should technically do all the cleanup for us.
If we install it, we should be able to remove it, and not know that it ever existed.
Our training courses are built modularly, and we can develop a customized training roadmap for your organization, so that everyone gets the training they need, when they need it.