posts/Package_management.mdwn

   1 Lex Nederbragt posted [a question about version control and
   2 provenance][LN] on the [Software Carpentry][SWC] [discussion
   3 list][discuss].  I responded with my [Portage][]-based
   4 [workflow][WTK], but C. Titus Brown [pointed out a number of reasons
   5 why this approach isn't more widely used][CTB], which seem to boil
   6 down to “that sounds like more trouble than it's worth”.  Because
   7 recording the state of a system is important for [reproducible
   8 research][RR], it is worth doing *something* to clean up the current
   9 seat-of-the-pants approach.
  10
  11 Figuring out what software you have intalled on your system is
  12 actually a (mostly) solved problem.  There is a long history in the
  13 Linux ecosystem for [package management systems][PMS] that track
  14 installed packages and install new software (and any dependencies)
  15 automatically.  Unfortunately, there is not a consensus package
  16 manager across distributions, with [Debian][]-based distributions
  17 using [apt][], [Fedora][]-based distributions using [yum][], ….  If
  18 you are not the system administrator for your computer, you can either
  19 talk your sysadmin into installing the packages you need, or use one
  20 of a number of guest package managers ([Gentoo Prefix][prefix],
  21 [homebrew][], …).  The guest package managers also work if you're
  22 committed to an OS that doesn't have an existing native package
  23 manager.
  24
  25 Despite the existence of many high quality package managers, I know
  26 many people who continue to install significant amounts of software by
  27 hand.  While this is sustainable for a handful of packages, I see no
  28 reason to struggle through manual installations (subsequent upgrades,
  29 dependencies, …) when existing tools can automate the procedure.  A
  30 stopgap solution is to use language specific package managers ([pip][]
  31 for [[Python]], [gem][] for [Ruby][], …).  This works fairly well, but
  32 once you reach a certain level of complexity (e.g. integrating
  33 [Fortran][] and [[C]] extensions with [[Python]] in [SciPy][]), things
  34 [get difficult][SciPy-no-pip].  While language-specific packaging
  35 standards ease automation, they are not a substitute for a
  36 language-agnostic package manager.
  37
  38 Many distributions distribute pre-compiled, binary packages, which
  39 give fast, stable installs without the need to have a full build
  40 system on your local machine.  When the package you need is in the
  41 official repository (or a third-party repository), this approach works
  42 quite well.  There's no need to go through the time or effort of
  43 compiling [Firefox][], [[LaTeX]], [LibreOffice][], or other software
  44 that I interact with as a general a user.  However, my own packages
  45 (or actively developed libraries that use from my own software) are
  46 rarely available as pre-compiled binaries.  If you find yourself in
  47 this situation, it is useful to use a package manager that makes it
  48 easy to write source-based packages ([Gentoo][]'s [Portage][],
  49 [Exherbo][]'s [Paludis][], [Arch][]'s [packman][], …).
  50
  51 With source-based packaging systems, packaging an existing Python
  52 package is usually a matter of [listing a bit of
  53 metadata][ipythonblocks].  With [layman][], integrating your [[local
  54 packages|Gentoo_overlay]] into your [Portage][] tree is extremely
  55 simple.  Does your package depend on some other package in another
  56 oddball language?  Some wonky build tool?  No problem!  Just list the
  57 new dependency in your [ebuild][PMS-doc] (it probably [already
  58 exists][packages]).  Source-based package managers also make it easy
  59 to stay up to date with ongoing development.  [Portage][] supports
  60 live ebuilds that build fresh checkouts from a project's version
  61 control repository (use [[Git]]!).  There is no need to dig out your
  62 old installation notes or reread the projects installation
  63 instructions.
  64
  65 Getting back to the goals of reproducible research, I think that
  66 existing package managers are an excellent solution for tracking the
  67 software used to perform experiments or run simulations and analysis.
  68 The main stumbling block is the lack of market penetration ;).
  69 Building a lightweight package manager that can work easily at both
  70 the system-wide and per-user levels across a range of host OSes is
  71 hard work.  With the current fractured packaging ecosystem, I doubt
  72 that rolling a new package manager from scratch would be an effective
  73 approach.  Existing package managers have mostly satisfied their
  74 users, and the fundamental properties haven't changed much in over a
  75 decade.  Writing a system appealing enough to drag these satisfied
  76 users over to your new system is probably not going to happen.
  77
  78 [Portage][] (and [Gentoo Prefix][prefix]) get you most of the way
  79 there, with the help of well written [specifications][PMS-doc] and
  80 [documentation][devguide].  However, compatibility and testing in the
  81 prefix configuration still need some polishing, as does [robust binary
  82 packaging support][binary].  These issues are less interesting to most
  83 [Portage][] developers, as they usually run Portage as the native
  84 package manager and avoid binary packages.  If the broader scientific
  85 community is interested in sustainable software, I think effort
  86 channeled into polishing these use-cases would be time well spent.
  87
  88 For those less interested in adopting a full-fledged package manager,
  89 you should at least make *some* effort to package your software.  I
  90 have used software that didn't even have a `README` with build
  91 instructions, but compiling it was awful.  If you're publishing your
  92 software in the hopes that others will find it, use it, and cite you
  93 in their subsequent paper, it behooves you to make the installation as
  94 easy as possible.  Until your community coalesces around a single
  95 package management framework, picking a standard build system
  96 ([Autotools][], [Distutils][], …) will at least make it easier for
  97 folks to install your software by hand.
  98
  99 [LN]: http://lists.software-carpentry.org/pipermail/discuss-software-carpentry.org/2013-May/000529.html
 100 [SWC]: http://software-carpentry.org/
 101 [discuss]: http://lists.software-carpentry.org/listinfo.cgi/discuss-software-carpentry.org
 102 [Portage]: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1
 103 [WTK]: http://lists.software-carpentry.org/pipermail/discuss-software-carpentry.org/2013-May/000533.html
 104 [CTB]: http://lists.software-carpentry.org/pipermail/discuss-software-carpentry.org/2013-May/000534.html
 105 [RR]: http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=4720211
 106 [PMS]: http://en.wikipedia.org/wiki/Package_management_system
 107 [Debian]: http://www.debian.org/
 108 [apt]: http://wiki.debian.org/Apt
 109 [Fedora]: http://fedoraproject.org/
 110 [yum]: http://yum.baseurl.org/
 111 [prefix]: http://www.gentoo.org/proj/en/gentoo-alt/prefix/
 112 [homebrew]: http://mxcl.github.io/homebrew/
 113 [pip]: http://www.pip-installer.org/en/latest/
 114 [gem]: http://rubygems.org/
 115 [Ruby]: http://www.ruby-lang.org/
 116 [Fortran]: http://en.wikipedia.org/wiki/Fortran
 117 [SciPy]: http://www.scipy.org/
 118 [SciPy-no-pip]: http://www.scipy.org/Installing_SciPy/BuildingGeneral#head-fe5a03a1d9ad7414becca62672c1316dc91b5f88
 119 [Firefox]: http://www.mozilla.org/en-US/firefox/new/
 120 [LibreOffice]: http://www.libreoffice.org/
 121 [Gentoo]: http://www.gentoo.org/
 122 [Exherbo]: http://www.exherbo.org/
 123 [Paludis]: http://paludis.exherbo.org/
 124 [Arch]: http://www.archlinux.org/
 125 [packman]: https://www.archlinux.org/pacman/
 126 [ipythonblocks]: http://git.tremily.us/?p=wtk-overlay.git;a=blob;f=dev-python/ipythonblocks/ipythonblocks-9999.ebuild;hb=HEAD
 127 [layman]: http://layman.sourceforge.net/
 128 [PMS-doc]: http://www.gentoo.org/proj/en/qa/pms.xml
 129 [packages]: http://gpo.zugaina.org/
 130 [devguide]: http://devmanual.gentoo.org/quickstart/
 131 [binary]: http://article.gmane.org/gmane.linux.gentoo.devel/84964/
 132 [Autotools]: http://www.gnu.org/savannah-checkouts/gnu/automake/manual/html_node/Autotools-Introduction.html
 133 [Distutils]: http://docs.python.org/3/distutils/
 134
 135 [[!tag tags/tools]]
 136 [[!tag tags/programming]]