Component Deployment with Planet You Want It Where?
Total Page：16
File Type：pdf, Size：1020Kb
Component Deployment with PLaneT You Want it Where? Jacob Matthews University of Chicago [email protected] Abstract install it if necessary. Effectively, programmers get to treat every For the past two years we have been developing PLaneT, a pack- library, even those they write themselves, as a standard library, age manager built into PLT Scheme’s module system that simplifies giving them the advantages of libraries without the pain of library program development by doing away with the distinction between deployment. installed and uninstalled packages. In this paper we explain how Since PLaneT retrieves packages from a centralized reposi- PLaneT works and the rationales behind our major design choices, tory, it also establishes a component marketplace for developers; focusing particularly on our decision to integrate PLaneT into PLT it serves as a one-stop shop where they can publish their own pro- Scheme and the consequences that decision had for PLaneT’s de- grams and discover useful programs written by others. In effect, sign. We also report our experience as PLaneT users and developers PLaneT is an infrastructure that transforms PLT Scheme’s effec- and describe what have emerged as PLaneT’s biggest advantages tive standard library from a monolithic cathedral development ef- and drawbacks. fort into a bazaar where anyone can contribute and the most use- ful libraries rise to the top, buoyed by their quality and usefulness rather than an official blessing [11]. This bazaar-like development 1. Introduction reinforces itself to the benefit of all PLT Scheme users: in the two No matter how great your programming language is, it is always years since PLaneT has been included in PLT Scheme, users have harder to write a program in it yourself than it is to let someone contributed nearly 300,000 lines of new Scheme code in 115 pack- else write it for you. That is one reason why libraries are a big deal ages. in programming languages, big enough that some languages are In this paper, we explain our experience with building and main- associated as much with their libraries as they are with their core taining PLaneT, with particular attention to PLaneT’s more unusual features (e.g., Java with java.util and C++ with the STL). design features and how they have worked in practice. Section 2 But when you move away from the standard libraries that come sets the stage by briefly introducing some existing component sys- built in to your programming language, you can end up paying a tems such as the Comprehensive Perl Archive Network (CPAN) high price for your convenience. If your program depends on any with particular attention to their deployment strategies. Section 3 libraries, you have to make sure those dependences are installed then uses those other systems to motivate our goals for PLaneT. wherever your program will run. And any dependences those li- The next few sections explain how we tried to achieve those goals: braries have need to be installed too, and any dependences those li- section 4 explains our server design, section 5 explains our client braries have, and so on. If you don’t have any help with this task, it design with particular attention to our choice of integrating com- is often easier to avoid using too many libraries than it is to explain ponent deployment into the language rather than keeping it as an how to install dozens of dependences in a README file. A Scheme external program, section 6 discusses how PLaneT maintains PLT programmer in this situation might reasonably bemoan the fact that Scheme tool support, and section 7 explains a few complications the choice needs to be made: why, in a language like Scheme with we foresaw and tried to address in our design. In section 8 we try to so many great facilities for code reuse, is it so impractical to actu- assess how well our design has stood up over the two years PLaneT ally reuse code? has been in use. In this paper we describe our attempt at addressing that problem by presenting the PLaneT package distribution system built into 2. Some popular component systems PLT Scheme [5], a component-deployment tool that aims to make Before we explain the decisions we made for PLaneT, we need package distribution and installation entirely transparent. To the to explain some background on existing component systems, how extent possible, PLaneT does away with the notion of an uninstalled they work, and some of their pitfalls. The software development package: a developer can use any PLaneT package in a program just community has learned a lot about both the benefits of software by referring to it as though it were already installed, and whenever components and the problems they can cause. Probably the most anyone runs that program, the PLaneT system will automatically famous such problem is so-called “DLL hell,” a term coined to describe what can happen to a Microsoft Windows installation if DLLs (for “dynamically-linked libraries,” a component technol- ogy) are installed incorrectly. Under the DLL system, when a pro- gram wants some functionality from a DLL, it refers to the DLL by name only. This can become a problem because the DLL may evolve over the course of new releases; if two different programs both rely on different versions of the same library, then they cannot Proceedings of the 2006 Scheme and Functional Programming Workshop both be installed on the same system at the same time. Furthermore, University of Chicago Technical Report TR-2006-06 since DLLs have no particular package deployment strategy, soft- 157 ware installers have to install any necessary libraries themselves; The RubyGems system takes the convention a step farther; and if an installer overwrites a DLL it can inadvertently break other their “Rational Versioning Policy,” while not technically required programs, possibly even leading to a situation where the user’s en- of packages, is strongly recommended and explicitly supported by tire system is unusable. Microsoft has addressed this problem in their automatic installation tools. The rational versioning policy re- several ways; the most recent of which is its .NET assembly format, quires that a package’s version should be a dotted triple of numbers which includes metadata that includes versioning information [10]. (e.g., 1.4.2). Incrementing the first number indicates a backwards- Neither of those systems deal with component distribution — it incompatible change, incrementing the second number indicates a is the programmer’s responsibility to figure out some other way to backwards-compatible change that adds features, and an increment locate useful components and to arrange for them to be installed on of the last number indicates an internal change such as a bug-fix users’ computers, and if a user wants to upgrade a component then that should not be visible to users. The automatic installation tools it is up to that user to find and install it. Other component systems use these numbers to decide which version of a package to down- have done work to help with these tasks, though. For instance, load; if a package requests a package of version number at least CPAN [1] is a central repository of Perl libraries and scripts that 2.3.1, then the tool considers version 2.5.0 an acceptable substitute users can download, and tools allow users to install and upgrade but not version 3.4.2. these libraries automatically in some cases (more on this later). All of these systems are in some sense optimistic, because they The Ruby programming language features a similar system called all let a tool decide to substitute one version of a package for RubyGems [12]. Many Unix-like operating systems also feature another, and there is no way to know for certain that the program package distribution systems that address these problems; Debian’s making the request doesn’t depend on some hidden behavior that dpkg system [14], for instance, provides a central repository of differs between the two. Still, in practice this system seems to programs and shared libraries that users can automatically fetch, work out, since most programs are not so deeply tied to the inner install, and upgrade upon request. workings of libraries they depend on that changes to those libraries Since these systems try to do more than DLLs do, they have to will break them. solve more potential problems. The most major of these is that if a tool installs a new component that relies on functionality from other 3. Goals components, the tool must also install appropriate versions of those In 2003 we decided to build a “CPAN for PLT Scheme” called prerequisites if the user does not already have them. Identifying 1 the entire set of uninstalled prerequisites is not too difficult given PLaneT . We wanted our design to keep or improve on the good the right metadata, but automatically deciding what “appropriate” features of existing component systems while removing as many of means in this context is more of a challenge. For a human, the most the undesirable properties of those approaches as we could. Specif- appropriate version of a prerequisite would probably be the one that ically, we wanted to make it very easy for PLaneT to automatically provides all the functionality that the requiring component needs in retrieve and install packages and recursively satisfy dependencies the highest-quality way and has the fewest bugs. But an automatic with the best available packages, while giving package developers tool cannot hope to figure out which package that is, so it needs to as much flexibility as possible. We also wanted to make it easy for simplify the problem somehow.