Editing OEP:pkg
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
== Abstract == | == Abstract == | ||
This OEP refers to Octave's design of the pkg system. The purpose of this system | This OEP refers to Octave's design of the pkg system. The purpose of this system | ||
Line 9: | Line 7: | ||
This document attempts to design a solution for this. | This document attempts to design a solution for this. | ||
The main idea is to | The main idea of the solution is to keep database files with each package location | ||
and dependencies, and allow for the merge of such files. | |||
To allow reinstallation of the packages, we propose to keep the source of the package. | |||
This would also make it easier to run the tests of packages. | |||
packages | |||
== Rationale == | == Rationale and examples == | ||
This design is meant to | This design is meant to allow the following: | ||
* | * keeping multiple versions of the same package installed and load a specific one | ||
* keep multiple versions of Octave in | * keep packages installed for multiple versions of Octave, specially in the case of | ||
.oct files which need to be rebuilt for each octave function | |||
* reinstall a package from its cache after installing new octave version | |||
* reinstall a package | * run the tests from packages (find tests in .cc sources) | ||
* | * clean the package cache | ||
* usage of alternate database files | |||
* usage of packages in remote directories which may not be available at all | |||
times | |||
* | |||
* | |||
== Available vs Loaded == | == Available vs Loaded == | ||
To avoid problems reading this document, the distinction between available and loaded | To avoid problems reading this document, the distinction between available and loaded | ||
package should be done early. | package should be done early. An available package is a package that is currently | ||
available to pkg to loading, unloading or reinstall. It is already installed but not necessarily loaded. | |||
An available package is a package that is currently available to pkg | A loaded package is an installed package whose functions have been added to Octave's function search | ||
unloading or reinstall. It is already installed but not necessarily loaded. | path. | ||
A loaded package is an installed package whose functions have been added to Octave's | |||
function search path. | |||
== Types of package installs == | == Types of package installs == | ||
This design supports 3 types of package installations: global (relative to the | This design supports 3 types of package installations: global (relative to the octave installation), local (user specific) and external (in any other place). Note that Octave itself can be installed in some different ways. It might be a system-wide installation (located somewhere in /usr/local/ for example), a local installation of a normal user (somewhere on /home/user/anywhere), or installed in the home directory of a system user (can be anywhere). | ||
Note that Octave itself can be installed in some different ways. It might be a system-wide | |||
installation (located somewhere in | |||
of a normal user ( | |||
directory of a system user (anywhere | |||
=== Global installs === | === Global installs === | ||
Packages installed globally will be available to everyone from startup. This is the | Packages installed globally will be available to everyone from startup. This is the | ||
type of package installation that a system administrator would | type of package installation that a system administrator would do for example. The | ||
meaning of global here is relative to the Octave installation though. If an Octave | meaning of global here is relative to the Octave installation though. If an Octave | ||
installation is local (installed by a user in | installation is local (installed by a user in ~/usr/local), a global installation | ||
of a package will still place its files in the home directory of the user (in | of a package will still place its files in the home directory of the user (in | ||
~/usr/local/ as well). | |||
A global installation is performed automatically if the user installing the package | A global installation is performed automatically if the user installing the package | ||
has write permissions to those directories ( | has write permissions to those directories (localfcnfiledir and localapioctfiledir). | ||
In case it has no permissions, a local package installation is performed instead. | In case it has no permissions, a local package installation is performed instead. | ||
=== Local installs === | === Local installs === | ||
Local packages are specific to a user. They are located in that user home directory | Local packages are specific to a user. They are located in that user home directory | ||
into | into ann .octave directory. As with global package installations, they are available | ||
from startup. Unlike global, they are user specific, only available to the user that | from startup. Unlike global, they are user specific, only available to the user that | ||
installed it. A local install for a user can be an external install for some other | installed it. A local install for a user can be an external install for some other | ||
user. | user. | ||
=== External installs === | === External installs === | ||
These are like local packages but in a non-standard location. Octave does not know | These are like local packages but in a non-standard location. Octave does not know | ||
about this installations at startup even | about this installations at startup even if the installation was done with the same | ||
Octave version. These can be packages installed in a filesystem that is not always | |||
filesystem that is not always mounted, local packages installs from another user | mounted, local packages installs from another user in the same system, or anything | ||
in the same system, or anything else really. | else really. | ||
An external package was | An external package was installed with pkg, it is simply not constantly tracked down | ||
by Octave. An external package install will have a .db associated file just like the | |||
associated file just like the db files for the local installs. To load an external | .db files for the local installs. To load an external package, the path for the .db | ||
package, the path for the db file needs to be passed to pkg and the db named | file needs to be passed to pkg and the db named. Then packages from there can be | ||
there | loaded. | ||
For example, after starting an Octave session, one can load two .db files. One is | |||
the labdev (/mnt/labdev/octave_packages.db) and the other is the friendA | |||
(/home/friendA/.octave/octave_packages.db). Once these two external db are loaded, | |||
the packages associated with it are made available to pkg and can be loaded normally. | |||
It's possible that the same package name and version exists in both dbs hence the | |||
need to name them (so it's possible to specify from which one should a package be loaded). | |||
== Package names == | == Package names == | ||
For | For parsing of the commands and files, some limitations on package names are required. This will | ||
limit what pkg commands can do. For example, if a package name is allowed to use | limit what pkg commands can do. For example, if a package name is allowed to use score, then | ||
commands such as "pkg load image-2.0.0" can no longer be used to load a specific package version. | commands such as "pkg load image-2.0.0" can no longer be used to load a specific package version. | ||
Something such as "pkg load image::2.0.0" would have to be used. Using this alternative syntax | Something such as "pkg load image::2.0.0" would have to be used. Using this alternative syntax | ||
Line 136: | Line 91: | ||
Also, supporting multiple packages versions means that the word "all" to refer to all | Also, supporting multiple packages versions means that the word "all" to refer to all | ||
packages has new limitations. Should we load only the latest version of each package? | packages has new limitations. Should we load only the latest version of each package? | ||
And if there's multiple packages with the same version on | And if there's multiple packages with the same version on varios db, which one should | ||
be loaded? I'd propose the default to be: | be loaded? I'd propose the default to be: | ||
- load the latest version | - load the latest version availale | ||
- load the local install of the package | - load the local install of the package | ||
- load the global install of the package | - load the global install of the package | ||
Line 145: | Line 100: | ||
For package names, the proposal is to limit package names to the same as variable | For package names, the proposal is to limit package names to the same as variable | ||
names (makes it even easier to check | names (makes it even easier to check validaity with isvarname). So package name | ||
must start with a letter, and otherwise be comprised of alphanumeric and underscores | must start with a letter, and otherwise be comprised of alphanumeric and underscores | ||
characters. Unlike variable names, package names will not be case sensitive since | characters. Unlike variable names, package names will not be case sensitive since | ||
Line 152: | Line 107: | ||
systems). | systems). | ||
== User cases == | == User cases == | ||
=== | === Case 1 === | ||
Denise installs Octave 3.4.3 and installs the latest version of the financial (1.0.4) and | Denise installs Octave 3.4.3 and installs the latest version of the financial (1.0.4) and | ||
image (2.0.0) package with "pkg install -forge financial image". After installing the packages, | image (2.0.0) package with "pkg install -forge financial image". After installing the packages, | ||
Line 251: | Line 117: | ||
tests in the package (using the cached package to run the tests in the .cc files). | tests in the package (using the cached package to run the tests in the .cc files). | ||
Later, Denise installs Octave 3.6.2 but keeps the previous version of Octave on the | Later, Denise installs Octave 3.6.2 but keeps the previous version of Octave on the | ||
system since some of her old code no longer runs correctly. Loading the financial | system since some of her old code no longer runs correctly. Loading the financial | ||
Line 266: | Line 132: | ||
While using Octave 3.6.2, Denise installs the new version of the package | While using Octave 3.6.2, Denise installs the new version of the package | ||
"pkg install -forge financial". The files for the previous version of the package | "pkg install -forge financial". The files for the previous version of the package | ||
are kept | are kept altough "pkg load financial" will only load the latest version. However, when | ||
Denise is using Octave 3.4.3, as financial 1.2.0 requires Octave 3.6.0, pkg load | Denise is using Octave 3.4.3, as financial 1.2.0 requires Octave 3.6.0, pkg load | ||
will only load financial 1.0.4. | will only load financial 1.0.4. | ||
=== | ==== comments ==== | ||
shouldn't `rebuild` be used instead of `reinstall` ? | |||
=== Case 2 === | |||
Owen is stuck using the financial package 1.0.4 because some of his code no | Owen is stuck using the financial package 1.0.4 because some of his code no | ||
longer works in the latest versions. However the latest version of financial | longer works in the latest versions. However the latest version of financial | ||
Line 280: | Line 150: | ||
while "pkg load financial" always loads the latest version of the package. | while "pkg load financial" always loads the latest version of the package. | ||
=== | === Case 3 === | ||
Lisa is using Octave in a remote machine on the biochemistry department. The | Lisa is using Octave in a remote machine on the biochemistry department. The | ||
system administrator installed Octave 3.6.2, signal package 1.2.0, and | system administrator installed Octave 3.6.2, signal package 1.2.0, and | ||
general 1.0.0. | general 1.0.0. Lisas uses all of them but she also requires the image package. | ||
However, the system administrator does not have time to access security issues | However, the system administrator does not have time to access security issues | ||
with the package and tells her to install that package locally. She runs "pkg | with the package and tells her to install that package locally. She runs "pkg | ||
Line 290: | Line 160: | ||
When Octave 3.6.3 is released, Lisa wants to use the new version since it fixes | When Octave 3.6.3 is released, Lisa wants to use the new version since it fixes | ||
one bug that has been | one bug that has been aanoying her for a long time but the system administrator | ||
does not want to make the update and tells her to build it herself locally | does not want to make the update and tells her to build it herself locally | ||
=== | === Case 4 === | ||
Diana is a student that wants to run her code in the departmental cluster. However, | Diana is a student that wants to run her code in the departmental cluster. However, | ||
the system does not have an installation of Octave and she needs to install it on | the system does not have an installation of Octave and she needs to install it on | ||
Line 314: | Line 184: | ||
to her own list of available packages. which she can load. | to her own list of available packages. which she can load. | ||
=== | ==== comments ==== | ||
:Why not store the "packages.db" together with the packages? instead of loading the a packages database file. Then, Diana could just say {{Codeline|pkg addpath ~Ligia/octave}} | |||
:: Because she might want to use some of her packages, not all. This adding the .db file to her instance of Octave will not load the package, she still needs to load it. And she may want to load only some of them. | |||
=== Case 5 === | |||
John is a professor of biomechanics and uses Octave on his classes. Most of the | John is a professor of biomechanics and uses Octave on his classes. Most of the | ||
exercises he gives to the class require the use of multiple packages in Octave | exercises he gives to the class require the use of multiple packages in Octave | ||
Line 320: | Line 195: | ||
metapackage for his student listing all required packages. The students install | metapackage for his student listing all required packages. The students install | ||
it with "pkg install -url path-to-his-metapackage". The metapackage has no file | it with "pkg install -url path-to-his-metapackage". The metapackage has no file | ||
it simply lists a bunch of package | it simply lists a bunch of package has dependencies. Since pkg solves this | ||
dependencies automatically, a message showing which packages will be installed | dependencies automatically, a message showing which packages will be installed | ||
is displayed before doing it. | is displayed before doing it. | ||
= | === Where to install things === | ||
== Where to install things == | |||
These should not be hardcoded and taken from octave_config_info. There's many paths there whose purpose is explained on octave sources [http://hg.savannah.gnu.org/hgweb/octave/file/default/build-aux/common.mk buil-aux/common.mk] (see the ''Where To Install Things'' and ''Octave-specific directories'' sections on that file.) | These should not be hardcoded and taken from octave_config_info. There's many paths there whose purpose is explained on octave sources [http://hg.savannah.gnu.org/hgweb/octave/file/default/build-aux/common.mk buil-aux/common.mk] (see the ''Where To Install Things'' and ''Octave-specific directories'' sections on that file.) | ||