|
|
Line 220: |
Line 220: |
| * '''Mentors''' | | * '''Mentors''' |
| : Mike Miller, Colin B. Macdonald, Abhinav Tripathi, others? | | : Mike Miller, Colin B. Macdonald, Abhinav Tripathi, others? |
|
| |
|
| |
| === Octave Package management ===
| |
|
| |
| [[Packages]] are extensions for Octave, that are mainly maintained by the [[Octave Forge]] community.
| |
| To get those extension to work with Octave, there is a single function, {{manual|pkg}}, which does pretty much everything.
| |
| This function has a few limitations which are hard to implement with the current codebase, and will most likely require a full rewrite.
| |
| A major step forward for a rewritten package manager is the [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project] by Andrew Janke.
| |
|
| |
| The planned improvements (see also {{bug|39479}}) are:
| |
|
| |
| * install and update from repositories (hg and git)
| |
| * automatic handling of dependencies
| |
| * easily load, update or check specific package versions
| |
| * management of tests and demos in C++ sources of packages
| |
| * more flexibility on dependencies, e.g., dependent on specific Octave build options or being dependent in one of multiple packages
| |
| * support for multiple version packages
| |
| * support for multiple Octave installs
| |
| * support for system-wide and user installed packages
| |
| * testing packages (<code>pkg test <package-name></code>)
| |
| * improved metadata acquisition (<code>pkg list -forge</code>) from https://octave.sourceforge.io/
| |
|
| |
| The main objective of this project is to make {{manual|pkg}} more user friendly and to make it a tool to foster third party participation in Octave.
| |
| However, the current {{manual|pkg}} also performs some maintenance functions which it probably should not.
| |
| Instead a package for developers should be created with such tools.
| |
| To do this enhancement effectively, a refactoring of the current {{codeline|pkg}} code will be needed (see [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project]).
| |
|
| |
| Many of these problems have been solved in other languages.
| |
| Familiarity with how other languages handle this problem will be useful to come up with elegant solutions.
| |
| In some cases, there are standards to follow.
| |
| For example, there are specifications published by freedesktop.org about where files should go ([http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html base directory spec]), and Windows seems to have its own standards.
| |
| See bugs {{bug|36477}} and {{bug|40444}} for more details.
| |
|
| |
| In addition, package names may start to collide very easily.
| |
| One horrible way to work around this by is choosing increasingly complex package names that give no hint on the package purpose.
| |
| A much better is option is providing an Authority category like Perl 6 does.
| |
| Nested packages is also an easy way to provide packages for specialized subjects (think {{codeline|image::morphology}}).
| |
| A new {{manual|pkg}} would think all this things now, or allow their implementation at a later time.
| |
| Read the [[OEP:pkg|unfinished plan]] for more details.
| |
|
| |
| * '''Minimum requirements'''
| |
| : Ability to read and write Octave code, experience with Octave packages, and understanding of the basics of autotools. The most important skill is software design.
| |
| * '''Difficulty'''
| |
| : Medium.
| |
| * '''Mentor'''
| |
| : [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco, Sebastian Schöps
| |
|
| |
|
| == Image Analysis == | | == Image Analysis == |