Re: Going to start Octave Package Management.

[Andrew Janke]

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:
>     http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html
>      >
>      >
>     "I don't know if it is a bug or not" - forget about 'pkg.m' for a
>     while.
>
> 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.

Cheers,
Andrew