Summer of Code - Getting Started: Difference between revisions

Jump to navigation Jump to search
→‎Infrastructure: Octave Package management, too ambitious for GSoC, move to Projects.
(→‎Infrastructure: Jupyter Notebook Integration too ambitious for GSoC.)
(→‎Infrastructure: Octave Package management, too ambitious for GSoC, move to Projects.)
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 ==

Navigation menu