LevT
Platinum Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
- [Voiceover] In this video, I'll explore the idea of a Package Manager and talk about how they differ from traditional Windows installers. Package managers are also known as package installers in some circles. They have an extensive history in the Operating System and developer communities. They have an interesting name, but really, they are just a special type of installer. You can break down package managers into two general categories. Operating system package managers, which are staples in operating systems like Linux. The other category is the Application package manager, sometimes called a programmer package manager.
This is the most common type of package manager for developer tools, NuGet fits in this category. Before exploring more, let's review the traditional installer. If you are a long-time desktop computer user, you probably have a good idea at what I mean when I say application installer. In the Windows world, the installation process looks like this. A customer gets the installer file, in the old days that would be from a CD or DVD, nowadays it comes from a website. This installer is a single file, usually an exe or msi file. The customer runs the installer, which prompts the user for information or asks the user to select settings from the installer dialog.
Often you have to make choices within the dialog, like where to install the application or what additional features should be installed. Then the installer does the work and after a few minutes, or hours, the app is installed. During the process, the computer gets updated. The registry might be changed, old DLL's could be removed, and directories added to the hard drive. Now let's contrast that with the App Store experience. On a mobile device, or on some of the newer operating systems like Windows 10, you have an App Store. All the apps are available in the store, the customer only has a single place to look for the app.
They look through the app list, pick the app, and touch the install button. At this point, the customer may see a payment screen and there is usually a capability screen shown which informs the customer what censors and features the app can access on the phone. Next the store installs the app in a known location. The customer takes no further action. The package manager experience is a mashup of these two installer techniques. Overall, the experience of installing software packages feels more like the App Store model. So here are the basic components of a package manager system.
Packages are created by various software publishers. They can be big companies, open store syndicates, or one man shops. Each package has a name and version number. The packages are published in a standard format maintained by the package manager system. The package contains all the code and data necessary to install on the developer computer. The packages are deployed to a central "code store" or online repository. This is where the similarity with app stores is apparent. The developer installs the package manager client on their local developer computer.
Using the client, the developer searches for a package in the online code store. When the correct package is located, the developer activates the install. Now the files are downloaded and installed and the software project is configured to work with the new package. One of the key differentiators for package management systems is the way they handle dependencies. Let's examine how dependencies work with traditional installers. Imagine for a moment you have two developer libraries, created by different companies. Library A from Company X and Library B from Company Z. Each company builds its own installer.
One installer is based on MSI technology, the other is based on InstallShield. So the install experience and installer UI is different for each library. Okay, that's not a show stopper, but let's continue. Library A has a dependency on library B. To use library A in your app, you'd have to download and run both installers. In some situations it might be possible to bundle the installers, but this is not the norm. Legal issues and licensing can hinder this approach. A more troubling issue is managing versions when libraries are updated.
When you install library A, version 1.2, you have to install library B, version 4.0. But if you work with library A, version 2.0, you have to install library B, version 4.1. This can get messy as you start adding additional dependencies to library A. So package managers use a more sensible approach to dependencies. Programmer package managers are aimed at developers. We are always creating libraries and tools that are dependent on other library. So package managers are written to support dependencies in intelligent ways.
They understand the dependencies. This is possible because each app package contains a list of its dependencies. What other packages in the code store are required for this package to function properly. This means the package manager automatically handles installing, updating, and removing dependencies when needed. The dependency packages can be published by other companies, but the friction seen in the old model is not there. That's because all the packages are located in the same online code repository. Generally, package managers are a good idea for the programmer.
As you look at different languages, you see there is usually an established leader, the package manager that is used by the community of developers. Here is a list of some of the popular package managers and their associated languages. If you are moving to dot NET from any of these languages, you'll find NuGet works in a similar fashion to your favorite package manager.
|
Всего записей: 17167 | Зарегистр. 14-10-2001 | Отправлено: 13:06 30-12-2017 | Исправлено: LevT, 14:31 30-12-2017 |
|
