Chalmers University of Technology
Julia 1.0 comes with a brand new package manager under the working name Pkg3. It has been rewritten from scratch based on the experiences of the previous package managers—both Julia’s an those in other languages. This talk discusses some of the design and implementation choices made and the reason behind them. Some of the topics included in the talk are: Federated package ecosystem. This means that multiple independent parties can maintain both public and private packages and registries of them, and that projects can depend on a mix of public and private packages from different registries. Packages from various registries are installed and managed using a common set of tools and workflows. One consequence of federation is that there cannot be a central authority for package naming: different entities may use the same name to refer to unrelated packages. Instead, packages are identified by universally unique identifiers (UUIDs) assigned to them prior to registration. UUIDs are mostly invisible to the casual user of Julia—they are used in project and manifest files maintained by the package manager but regular Julia code continues to use packages by name as it always has. Environments. Julia’s code loading and package manager natively support having multiple independent sets of packages at different versions. This alleviates “DLL hell” for Julia packages since unrelated projects don’t need to fight about what version of their dependencies to use—they can each use whatever version of a dependency they prefer. Manifest files record the exact version of each dependency in a complete dependency graph for a given application and can be reconstituted with a single command on the same system or a different one—a huge boon for reproducibility. Immutability and content addressing. One of the basic design principles of Pkg3 is that an installed version of a package is immutable and identified by its content. In other words, once a version of a package is installed, it is never changed and anyone who wants that version asks for by a hash of its source tree. When a version is no longer needed anywhere, it is automatically deleted. Identifying package versions by content rather than git commit also means that packages are free to rewrite their development history—for example to discard large objects—and allows packages to be installed without any need for git history at all, so long as the source tree is correct.
Ph.D. student in computational mechanics at Chalmers University of Technology. Using Julia both for studies and as a hobby.
