[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Going to start Octave Package Management.

From: Andrew Janke
Subject: Re: Going to start Octave Package Management.
Date: Thu, 7 Feb 2019 15:12:45 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.0

On 2/4/19 12:27 PM, Nicholas Jankowski wrote:

On Mon, Feb 4, 2019 at 10:58 AM Sergei Steshenko <address@hidden <mailto:address@hidden>> wrote:

     > --
     > Sent from:
    "I don't know if it is a bug or not" - forget about 'pkg.m' for a

A good point.  a different line of thought might be - how do current package managers that can handle presence of multiple installed versions handle a general "update all" request?   I think users would generally expect a blanket 'pkg update' like function. Does python's pip allow it? what about OS package managers?

Here's how a few different package managers I know handle this:

pip only installs a single version of each package at a time. "upgrade" upgrades all packages to the latest version, removing the old version. Multiple versions are handled through virtual environments.

conda only installs a single version of each package at a time. "upgrade" upgrades all packages to the latest version, removing the old version (unless you have pins, and within the version-range requirements in your environment specification, in which case it will just keep the old version and not install a new version). Multiple versions are handled through virtual environments.

Ruby's gem can install multiple versions of a package at the same time in a single environment. It also supports virtual environments through both RVM and bundler. "gem update" will install the latest version of each installed package, and will also leave all previously-installed versions still installed, so it just adds new installed versions.

I don't know how NVM works.

Homebrew can install multiple versions side-by-side, but since it only stores a definition for the latest version of a package, the only way to do this is to have a pre-existing installation in place from an older Homebrew version. "upgrade" installs the latest version of all packages, and will leave older versions in place only if it detects that other installed "kegs" have a dependency on them (at the native library linkage level, by looking at .dylibs). It will automatically remove older versions if it detects no lingering dependencies on them, at the time of the upgrade. A separate "cleanup" operation will remove old retained versions once they are no longer depended on (if they were originally retained at upgrade time due to keg dependencies). But only the latest version of the package is "linked" and active (visible) in the system at large. No virtual environment support; if you want scenarios with different versions, you install multiple complete Homebrew installations at different paths and switch between them by manipulating your $PATH.

There are also version-aware dependency managers like Maven to consider. Maven doesn't have a global installation location; all installations are local to a build. All dependencies are specified to an exact version, and having multiple versions of a given package in a dependency graph is an error, so there's no support for multiple versions of a package in a given environment.

apt and all other Linux distro package managers that I'm aware of only install a single version of a package at a time. (I think.) Side-by-side installations of different versions of a program or library are handled by making them distinct packages and incorporating part of the version number in the package name. (Homebrew does this too.) "upgrade" upgrades everything to the latest version, removing old versions. This is probably a consequence of the fact that Linux packages install stuff into global system locations instead of segregated per-package spaces.

Let's consider: if pkg supports multiple-versioning, does it want to handle selection of those versions via a "virtual environment" mechanism where you have scoped installations, or by selection of package versions at "pkg load" time?

This stuff has actually been on my mind lately because I'm working on a package manager for Matlab that will work similarly to Octave's pkg, and will also have multiple-version support. I'm leaning toward doing version resolution by having multiple versions of packages all installed in a single scope, and selecting versions at "pkg load" time using "package sets", which are possibly-named sets of (package, versionspec) pairs, where versionspec may be an exact version or a set of "version </<=/==/>=/>/!=" requirement specifiers. I prefer this to the "virtual environment" approach because virtual environments (that I've seen) require you to instantiate the installation of each particular combination of library versions you want to run against; in a testing scenario, I'd like to test against all the combinations of, say, the last 3 versions of 5 libraries I'm coding against, and I want to just load in each combination dynamically instead of having to manage 15 named environments.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]