DOCSLIB.ORG

A Survey of Linux Metadata Package Management Systems and Their Solvers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Survey of Linux Metadata Package Management Systems and Their Solvers A SURVEY OF LINUX METADATA PACKAGE MANAGEMENT SYSTEMS AND THEIR SOLVERS. 1SRIKALA BHARADWAJ, 2MEGHA.P.ARAKERI 1,2Information Science Department, MSRIT, Bangalore Abstract— Software components which encapsulate units of functionality for an operating system is created and widely distributed to end users in packaged forms such as RPM package manager (RPM) format or debian format in many Linux distros. Many Linux flavours make use of primary package managers with secondary metadata package managers to handle the installation, upgradation and removal of packages. This is a survey paper that delves into the world of metadata package management and examines the various techniques used by the package managers available today. Index Terms—Package Management, Dependency Hell, Dependency Resolution, Automatic install, Upgrade. I. INTRODUCTION logic that is to be executed during deployment and metadata that helps track the files and describe the Software created can be shipped to an end user either component’s capabilities. For example in the RPM in source form or in pre-built package form. The format all the metadata is present in a header. A source form is configurable to ones needs and so is software package can be visualized as shown in Fig.2. preferred by developers who configure, build and install it as per their requirements. But management of this becomes a tedious task with time. A typical end user prefers to use a pre-built ready to install packaged application. Package maintainer takes the burden of configuring, building and packaging it. A package will have the installation paths, information about packages that the current package is dependent upon, patches and scripts. A typical open operating system consists of thousands of software components that help run various applications. These components are made available as packages. An operating system may about have 25000 to 45000 packages. Fig. 2 Contents of a typical package Package Repository: This is usually a web repository (hosted on a File transfer protocol (FTP) server), or a media device such as DVD where all packages are made available by packager for install. Package Manager: It is a tool that handles dependency resolution, fetching the packages from repository, installation, upgradation and removal of packages Fig. 1 Overview of package management from the repository. A basic package manager (such as RPM) is aided by a secondary metadata using package In order to consistently maintain installation, manager say Yellowdog Updater, modified (YUM). upgradation and removal of these software packages, a for automatic dependency resolution and other set of tools called package manager is used. The Fig.1 advanced features. shows the components involved in package distribution and management. A package is typically a Dependencies for a package: A package ‘A’ might piece of software which contains files to be placed in require package ‘B’ as a pre-install. So package ‘B’ is specific directories in the target system, configuration a dependency for package ‘A’. In the real world Proceedings of 6th IRF International Conference, Bangalore, India, 01st June, 2014. ISBN: 978-93-84209-24-7 88 A Survey Of Linux Metadata Package Management Systems And Their Solvers. scenario the dependencies tend to form a complex tree Rollback or undo the changes: When the recent like structure as shown in Fig.3 changes produce undesirable effects, it should be possible to rollback to a previous information profile. Frequent need for updating: There are newer versions of software available everyday which meets the user’s requirement better. Routine upgrades are done to provide security patches, fix bugs and new features. Scalability: A single repository contains thousands of packages. The real challenge arises when the package manager has to deal with multiple repositories. III. PACKAGE MANAGEMENT METHODOLOGIES A. Functional Package managers Nix [3] is a package manager based on a purely functional model. Packages are built from Nix expressions which are used to describe graphs of build actions called derivations. A derivation consists of a build script, environment variables and other Fig.3. Dependency tree for package yum derivations (set of dependencies). A package is built recursively from its dependencies and each time the In this paper we will see the workings of various corresponding build scripts and environment settings package managers and techniques used by them to are done. In order to perform an upgrade with a new solve the package install, upgrade and removal configuration, the system is entirely rebuilt with the problem. Section II gives the challenges in package new specification. This allows for an easy roll back to management. Section III gives the overview of the the old configuration if necessary. This model also types of package managers classified according to the benefits from its statelessness property. Statelessness method used to carry out the tasks-functional method makes the configuration actions predictable and and imperative method. Section IV looks particularly ensures there is no mysterious failure. into techniques used for dependency resolution. The similarities between modules (or units) used in Section V lists package managers whose programming and packages used in software computational burden is shifted to server side. Section distribution were highlighted by Tucker [4]. A VII gives the future trends likely to be seen in this area package and module have similar behaviour as both of research. provide their capabilities as a service and in turn may require certain imports. In programming context the II. CHALLENGES IN PACKAGE imports correspond to other functions and values MANAGEMENT whereas in package management context the imports are other modules or dependencies. The distribution Language to express user request: A simple install format would be a compound unit which is a bundle of command has to be expressed in a structural way [1] all necessary atomic units linked correctly. As seen in [2] such that the steps and dependencies required to the programming world where a class can be install it is input accurately into the package manager. instantiated as several objects similarly a unit can be Usually Conjunctive normal form or set theory invoked several times and separate copies of each expressions are used. invocation can be uniquely identified and maintained. Dependency resolution: Package manager should This makes a provision for using correct version of check whether a solution that satisfies all constraints dependencies without conflicting with other installed exists among the available packages. As the versions. Having multiple versions installed satisfiability criteria increases, the logical complexity simultaneously can aid in better rollback mechanism. of the problem also increases. Optimization: The best solution should be picked B. Imperative package managers among available solutions. User preference should be Most tools use imperative method [3] of operation taken into account for optimization. where the deployment actions are stateful. Files Unpacking and installing: The installation should be belonging to each package are stored in the Unix file done with minimal possible changes to the current system hierarchy. Packages are upgraded by information profile such that there are no broken overwriting the old versions. Statefulness makes it applications. hard to support multiple versions at the same time. These tools are capable of automatically resolving Proceedings of 6th IRF International Conference, Bangalore, India, 01st June, 2014. ISBN: 978-93-84209-24-7 89 A Survey Of Linux Metadata Package Management Systems And Their Solvers. 1 dependencies and installing the required package. p p represents conflict between the packages p They are less complex and hence are fast. The and p1. reliability however is less as they may not be able to When the propositional logic consists of all find a solution many-a-times. It is difficult to roll back dependency requirements in conjunctive form, the an installation or upgradation as configuration files problem can be solved in linear time. But if two or are manipulated without traceability. more packages satisfy the dependency and Cupt [5] is a partial reimplementation of APT with an disjunctions are used in the propositional logic, then it aim to achieve a bug-free package manager. The becomes a NP-complete problem [8]. Boolean optimization criterion is hard coded. In the satisfiability is a known NP-complete problem. Hence MISC-2010 [12] competition it was able to find a package upgrade request is also a NP-complete solution with 21% success for large set criterion (4 problem [7]. Debian releases) and 84% success for single release YaSt [9] package manager used by openSUSE Linux setup. uses Boolean satisfiability (SAT solver) to find Smart Package manager [6] is a platform agnostic dependencies. It uses an external solver libzypp. User portable tool. It aids the user with efficient solution preferences are hard coded in the problem encoding. finding algorithms and rollback options. In the MAX- SAT is a SAT based method where the effort is MISC-2010 competition Smart performed very well made to satisfy maximum number of clauses. with a single repository with 93% success of finding a INESC-ID [8] is a solver built using the p2cudf parser solution; however its performance degraded with the and MAX-SAT solver from MSUnCore which has an scaling of repository size and could provide solutions unsatisfiability core. In the MISC-2010 competition, with only 25% success. insec solver approximately had twice the penalty rate Mancoosi Package Manager (MPM) [7] is a of the winner. In took less time when the aim was to distribution-agnostic tool that uses the Common minimize the number of packages removed or Upgradeability Description Format (CUDF) format changed and worked best with direct CUDF input. It for describing package upgrade problem and found a solution with a success rate of 96% of which optimizations. MPM allows users to specify high level 12% were optimal. user optimization criteria. MPM architecture allows for use of external dependency solvers to be used by D.
Load more

Recommended publications
  • Using System Call Interposition to Automatically Create Portable Software Packages
    CDE: Using System Call Interposition to Automatically Create Portable Software Packages Philip J. Guo and Dawson Engler Stanford University April 5, 2011 (This technical report is an extended version of our 2011 USENIX ATC paper) Abstract as dependency hell. Or the user might lack permissions to install software packages in the first place, a common It can be painfully difficult to take software that runs on occurrence on corporate machines and compute clusters one person’s machine and get it to run on another ma- that are administered by IT departments. Finally, the chine. Online forums and mailing lists are filled with user (recalling bitter past experiences) may be reluctant discussions of users’ troubles with compiling, installing, to perturb a working environment by upgrading or down- and configuring software and their myriad of dependen- grading library versions just to try out new software. cies. To eliminate this dependency problem, we created As a testament to the ubiquity of software deployment a system called CDE that uses system call interposition to problems, consider the prevalence of online forums and monitor the execution of x86-Linux programs and pack- mailing list discussions dedicated to troubleshooting in- age up the Code, Data, and Environment required to run stallation and configuration issues. For example, almost them on other x86-Linux machines. The main benefits half of the messages sent to the mailing lists of two ma- of CDE are that creating a package is completely auto- ture research tools, the graph-tool mathematical graph matic, and that running programs within a package re- analysis library [10] and the PADS system for processing quires no installation, configuration, or root permissions.
    [Show full text]
  • Introduction to the Nix Package Manager
    Introduction Nix concepts Usage examples Conclusion Introduction to the Nix Package Manager Millian Poquet 2021-05-12 — Datamove (Inria) seminar 1 / 16 Introduction Nix concepts Usage examples Conclusion Why Nix? Control your software environment! Programs/libraries/scripts/configurations + versions Why is it important for us? Use/develop/test/distribute software Manually install many dependencies? No, just type nix-shell Shared env for whole team (tunable) and test machines Bug only on my machine? Means this is hardware or OS related Reproducible research Repeat experiment in exact same environment Introduce or test variation 2 / 16 Introduction Nix concepts Usage examples Conclusion What is Nix? Nix: package manager Download and install packages Shell into well-defined environment (like virtualenv) Transactional (rollback works) Cross-platform: Linux, macOS, Windows (WSL) Nix: programming language Define packages Define environments (set of packages) Functional, DSL NixOS: Linux distribution Declarative system configuration Uses the Nix language Transactional (rollback still works) 3 / 16 Introduction Nix concepts Usage examples Conclusion Nix in numbers Started in 2003 Nix 1: 10k commits, 28k C++ LOC Nixpkgs 2: 285k commits, 55k packages 3 1. https://github.com/NixOS/nix 2. https://github.com/NixOS/nixpkgs 3. https://repology.org/repositories/statistics 4 / 16 Introduction Nix concepts Usage examples Conclusion Presentation summary 2 Nix concepts 3 Usage examples 4 Conclusion 5 / 16 Introduction Nix concepts Usage examples Conclusion Traditional
    [Show full text]
  • Chapter 7 Package Management
    Chapter 7 Package Management CERTIFICATION OBJECTIVES 7.01 The Red Hat Package Manager ✓ Two-Minute Drill 7.02 More RPM Commands Q&A Self Test 7.03 Dependencies and the yum Command 7.04 More Package Management Tools fter installation is complete, systems are secured, filesystems are configured, and other initial setup tasks are completed, you still have work to do. Almost certainly before your system is in the state you desire, you will be required to install or remove packages. To make sure the right updates are installed, you need to know how to get a system working with ARed Hat Subscription Management (RHSM) or the repository associated with a rebuild distribution. To accomplish these tasks, you need to understand how to use the rpm and yum commands in detail. Although these are “just” two commands, they are rich in detail. Entire books have been dedicated to the rpm command, such as the Red Hat RPM Guide by Eric 344 Chapter 7 Package Management Foster-Johnson. For many, that degree of in-depth knowledge of the rpm command is no longer necessary, given the capabilities of the yum command and the additional package management tools provided in RHEL 7. CERTIFICATION OBJECTIVE 7.01 The Red Hat Package Manager One of the major duties of a system administrator is software management. New applications are installed. Services are updated. Kernels are patched. Without the right tools, it can be difficult to figure out what software is on a system, what is the latest update, and what applications depend on other software.
    [Show full text]
  • CDE: Run Any Linux Application On-Demand Without Installation
    CDE: Run Any Linux Application On-Demand Without Installation Philip J. Guo Stanford University [email protected] Abstract with compiling, installing, and configuring software and their myriad of dependencies. For example, the official There is a huge ecosystem of free software for Linux, but Google Chrome help forum for “install/uninstall issues” since each Linux distribution (distro) contains a differ- has over 5800 threads. ent set of pre-installed shared libraries, filesystem layout In addition, a study of US labor statistics predicts that conventions, and other environmental state, it is difficult by 2012, 13 million American workers will do program- to create and distribute software that works without has- ming in their jobs, but amongst those, only 3 million will sle across all distros. Online forums and mailing lists be professional software developers [24]. Thus, there are are filled with discussions of users’ troubles with com- potentially millions of people who still need to get their piling, installing, and configuring Linux software and software to run on other machines but who are unlikely their myriad of dependencies. To address this ubiqui- to invest the effort to create one-click installers or wres- tous problem, we have created an open-source tool called tle with package managers, since their primary job is not CDE that automatically packages up the Code, Data, and to release production-quality software. For example: Environment required to run a set of x86-Linux pro- grams on other x86-Linux machines. Creating a CDE • System administrators often hack together ad- package is as simple as running the target application un- hoc utilities comprised of shell scripts and custom- der CDE’s monitoring, and executing a CDE package re- compiled versions of open-source software, in or- quires no installation, configuration, or root permissions.
    [Show full text]
  • Conflict Resolution Via Containerless Filesystem Virtualization
    Dependency Heaven: Conflict Resolution via Containerless Filesystem Virtualization Anonymous Author(s) Abstract previous installation, effectively preventing concurrent ver- Resolving dependency versioning conflicts in applications sions of that library from coexisting. The same is true for is a long-standing problem in software development and packages whose executable names does not change across deployment. Containers have become a popular way to ad- releases; unless the user renames the existing executable dress this problem, allowing programs to be distributed in a files prior to the installation of a new version it is notpos- portable fashion and to run them under strict security con- sible to keep both installations around. The problem with straints. Due to the popularity of this approach, its use has that approach is that it breaks package managers, as the re- started to extend beyond its original aim, with users often named files will not be featured in the package manager’s creating containers bundling entire Linux distributions to database and, consequently, will not be tracked anymore. run mundane executables, incurring hidden performance Further, unless executables depending on the renamed files and maintenance costs. This paper presents an alternative are modified to reflect their new path, users need todefine approach to the problem of versioning resolution applied to which executable to activate at a given time, usually through locally-installed applications, through a virtualization tool tricky management of symbolic
    [Show full text]
  • Linux Package Management
    Welcome A Basic Overview and Introduction to Linux Package Management By Stan Reichardt [email protected] October 2009 Disclaimer ● ...like a locomotive ● Many (similar but different) ● Fast moving ● Complex parts ● Another one coming any minute ● I have ridden locomotives ● I am NOT a locomotive engineer 2 Begin The Train Wreck 3 Definitions ● A file archiver is a computer program that combines a number of files together into one archive file, or a series of archive files, for easier transportation or storage. ● Metadata is data (or information) about other data (or information). 4 File Archivers Front Ends Base Package Tool CLI GUI tar .tar, tar tar file roller .tar.gz, .tgz, .tar.Z, .taz, .tar.bz2,.tbz2, .tbz, .tb2, .tar.lzma,.tlz, .tar.xz, .txz, .tz zip .zip zip zip file roller gzip gzip gunzip gunzip ● Archive file http://en.wikipedia.org/wiki/Archive_file ● Comparison of file archivers http://en.wikipedia.org/wiki/Comparison_of_file_archivers 5 tar ● These files end with .tar suffix. ● Compressed tar files end with “.t” variations: .tar.gz, .tgz, .tar.Z, .taz, .tar.bz2, .tbz2, .tbz, .tb2, .tar.lzma, .tlz, .tar.xz, .txz, .tz ● Originally intended for transferring files to and from tape, it is still used on disk-based storage to combine files before they are compressed. ● tar (file format) http://en.wikipedia.org/wiki/.tar 6 tarball ● A tar file or compressed tar file is commonly referred to as a tarball. ● The "tarball" format combines tar archives with a file-based compression scheme (usually gzip). ● Commonly used for source and binary distribution on Unix-like platforms, widely available elsewhere.
    [Show full text]
  • Nix(OS) - Revolutionizing Packaging and Configuration Management!
    Nix(OS) - Revolutionizing packaging and configuration management! The Purely Functional Linux Distribution 1 Before we begin (FYI) Ask questions at any time Please ask lots of questions :) The slides contain some redundancy There are a few optional slides at the end Please give me feedback Louder Faster/slower More/less details Etc. 2 About me Michael Weiss aka. primeos Computer science student at the University of Tübingen I love free soware, etc. First nixpkgs commit: 2016-10-05 I maintain ~41 packages and ~3 modules (2018-06-08) I also love privacy (i.e. no more details :P) Email: [email protected] (#privacy) 3 Main components Nix (package manager) Nixpkgs (Nix packages collection) NixOS (operating system) NixOps (DevOps / cloud deployment tool) 4 Nix* ISO/OSI model NixOps NixOS Nixpkgs Nix 5 Other tools Hydra (Nix based continuous build system) Disnix (distributed services deployment) PatchELF (change dynamic linker and RPATH) {cabal,go,node,pip,python,pypi,composer,hex,bower,vim,...}2 6 History Started as a research project (with funding) First paper in 2004 (many will follow) Nix package manager developed by Eelco Dolstra as part of his PhD research (~2003) First NixOS prototype developed by Armijn Hemel as his master's thesis project Hydra developed as part of the LaQuSo Buildfarm project 7 Timeline 2003: init (research begins) 2007: NixOS becomes usable + x86_64 support 2008: Website moved to nixos.org 2009: Nix logo + Nix(OS) build on Hydra 2011: Migration from Subversion to Git(Hub) 2013: Switch from Upstart to systemd +
    [Show full text]
  • A Graybeard's Worst Nightmare
    A Greybeard's Worst Nightmare How Kubernetes and Containers are re-defining the Linux OS Daniel Riek Fosdem 2020 1 Introduction ● Name: Daniel Riek Twitter: llunved ● Using GNU/Linux since 1994 ● Co-founded Free Software start-up ID-Pro in Europe in 1997 ● Worked at Alcove, a french GNU/Linux company 2001-2003 ● Red Hat, EMEA Sales Engineering 2003-2005 ● Red Hat, ran RHEL Product Management 2005-2011 ● CTO at trading startup Vincorex 2011-2012 ● Product Management at back-up company Acronis 2012-2013 ● Red Hat, managing cross-product integration, container initiative 2013-2017 ● Red Hat, Office of the CTO, Artificial Intelligence since 2017 ○ Working on FOSS AI incl. projects such as https://opendatahub.io and https://github.com/thoth-station DISCLAIMER So yes, I work at Red Hat, which is a subsidiary of IBM. Red Hat is a Free and Open Source Cloud Software Company. However, while I may use the Red Hat stack as an example, nothing I say here can be misconstrued into an official position of any of my former, current, or future employers. It’s just me. Greybeard Greybeards fight Balrogs. They hate systemd. They fork distributions. The Role of the Linux OS Infrastructure or Application Application Platform? View GNU / Linux ● In abstract representations of the modern software stack, the OS is often considered part of the Infrastructure. Infrastructure ● However, an alternative, application-centric view would View consider it’s primary role to provide a common runtime for applications, abstracting from infrastructure. Meanwhile: Growing Software Stack Complexity Source: www.modulecounts.com Historic Role of GNU/Linux Breaking the vertical lock-in of Mainframe & Mini-Computers, UNIX MAINFRAME UNIX GNU/Linux - e.g.
    [Show full text]
  • Compiling and Installing Software, Manually Or Automatically, File Comparison J
    Compiling and installing software, manually or automatically, file comparison J. M. P. Alves Laboratory of Genomics & Bioinformatics in Parasitology Department of Parasitology, ICB, USP Software for all ● Operating systems nowadays, differently from the old times, come with a large selection of user applications installed by default ● Those are programs that we use most of the time: office software, web browsers, image editors, music players, games, etc. etc. etc. ● Linux distros such as Ubuntu and Debian include most of the commonly used programs in their default download image ● However, the universe of software is huge, and very diverse; it is not possible to include even a small sample of every kind of application that exists out there ● That is where being able to install other programs comes in handy J.M.P. Alves 2 / 55 BMP0260 / ICB5765 / IBI5765 Software for all ● Until the 1990s, the Internet was not as available for the general public as it is today, so software had to be distributed or copied in tape or disks (magnetic, like floppy disks, or optical, like CDs), or even printed 5.25” floppy, 3.5” floppy, 8” floppy, 175 kB to 1.2 MB 360 or 720 kB 1.44 MB J.M.P. Alves 3 / 55 BMP0260 / ICB5765 / IBI5765 40 years of external storage By avaragado, at http://flickr.com/photos/89394041@N00/6960433672 J.M.P. Alves 4 / 55 BMP0260 / ICB5765 / IBI5765 The modern era ● With the Web, anyone with an Internet connection became able to find software ● Certain specialized collections of software, called repositories, have been set up and serve as centralized sources ● Classical example in biological software, the IUBio Software section (since 1989!): http://iubio.bio.indiana.edu/software/ ● Many of these repositories are dedicated to a certain kind of software, e.g.
    [Show full text]
  • Journal of Functional Programming Nixos: a Purely Functional Linux
    Journal of Functional Programming http://journals.cambridge.org/JFP Additional services for Journal of Functional Programming: Email alerts: Click here Subscriptions: Click here Commercial reprints: Click here Terms of use : Click here NixOS: A purely functional Linux distribution EELCO DOLSTRA, ANDRES LÖH and NICOLAS PIERRON Journal of Functional Programming / Volume 20 / Special Issue 5­6 / November 2010, pp 577 ­ 615 DOI: 10.1017/S0956796810000195, Published online: 15 October 2010 Link to this article: http://journals.cambridge.org/abstract_S0956796810000195 How to cite this article: EELCO DOLSTRA, ANDRES LÖH and NICOLAS PIERRON (2010). NixOS: A purely functional Linux distribution. Journal of Functional Programming,20, pp 577­615 doi:10.1017/ S0956796810000195 Request Permissions : Click here Downloaded from http://journals.cambridge.org/JFP, by Username: nrnr, IP address: 108.20.67.9 on 31 Aug 2012 JFP 20 (5 & 6): 577–615, 2011. c Cambridge University Press 2010 577 doi:10.1017/S0956796810000195 First published online 15 October 2010 NixOS: A purely functional Linux distribution EELCO DOLSTRA Department of Software Technology, Delft University of Technology, Postbus 5031, 2600 GA Delft, The Netherlands (e-mail: [email protected]) ANDRES LOH¨ Department of Information and Computing Sciences, Utrecht University, Postbus 80 . 089, 3508 TB Utrecht, The Netherlands (e-mail: [email protected]) NICOLAS PIERRON EPITA Research and Development Laboratory, 14-16 rue Voltaire, 94276 Le Kremlin-Bicetreˆ cedex, France (e-mail: [email protected]) Abstract Existing package and system configuration management tools suffer from an imperative model, where system administration actions such as package upgrades or changes to system configuration files are stateful: they destructively update the state of the system.
    [Show full text]
  • Dependency Solving Is Still Hard, but We Are Getting Better at It
    Dependency Solving Is Still Hard, but We Are Getting Better at It Pietro Abate Roberto Di Cosmo Georgios Gousios Stefano Zacchiroli Nomadic Labs Inria and Universite´ de Paris Delft Univ. of Technology Universite´ de Paris and Inria Paris, France Paris, France Delft, The Netherlands Paris, France [email protected] [email protected] [email protected] [email protected] Abstract—Dependency solving is a hard (NP-complete) prob- attr library”, “uninstall version 3.5.4 of aiohttp”, and “install lem in all non-trivial component models due to either mutually version 3.6.2 of aiohttp from downloaded zip file”. incompatible versions of the same packages or explicitly declared Dependency solving is a hard problem in all non-trivial package conflicts. As such, software upgrade planning needs to rely on highly specialized dependency solvers, lest falling component models. It has first been shown to be NP-complete into pitfalls such as incompleteness—a combination of package in 2006 for expressive dependencies such as Debian’s [16]— versions that satisfy dependency constraints does exist, but the which allows version predicates (e.g., python3-aiohttp package manager is unable to find it. >= 3.0.1), AND/OR logical connectors, virtual packages, In this paper we look back at proposals from dependency and explicit inter-package conflicts. Intuitively, the difficulty of solving research dating back a few years. Specifically, we review the idea of treating dependency solving as a separate concern dependency solving comes from the fact that it is not enough in package manager implementations, relying on generic depen- to explore the dependency tree of the package you want to dency solvers based on tried and tested techniques such as SAT install, because you might need arbitrarily deep backtracking solving, PBO, MILP, etc.
    [Show full text]
  • Python Package Management Guide for Enterprise Developers Executive Summary
    Python Package Management Guide for Enterprise Developers Executive Summary Package management continues to evolve, but traditional Python package managers are slow to catch up. Enterprise developers must deal with the consequences, including: Poor Environment Reproducibility - slightly different configurations across environments result in “works on my machine” issues and time wasted reproducing bugs, delaying time to market. Supply Chain Security - installing unsigned binaries with package managers is convenient, but risky. On the other hand, building packages from source for multiple operating systems is painful, especially if they require linked C libraries. Choosing the Right Packages/ Versions - how can you be sure you are always choosing the correct, approved open source components and versions required by your organization? Fixing Vulnerabilities - investigating vulnerabilities, patching/updating components and rebuilding environments are time and resource intensive, leaving less time for coding. The ActiveState Platform addresses these issues, helping Python development teams in enterprises to: Create consistent, reproducible Python environments that can be deployed on a given system with a single command. Automatically build Python environments (including C libraries) from source code, resolving dependencies and packaging the result for all popular operating systems. Always know which components/versions are approved for use. Identify vulnerable components, fix them, and automatically rebuild secure environments quickly and easily. If you wrestle with any of these issues, adopting the ActiveState Platform will allow you to spend more time coding and less time managing packages and environments. All of which means you’re more likely to complete your sprint deliverables on time. Page 2 The State of Python Package Management As a Python programmer, you know that package management has been a work in progress for decades.
    [Show full text]