Octave

Summer of Code - Getting Started: Difference between revisions

Page Discussion

Summer of Code - Getting Started (view source)

Revision as of 08:48, 23 March 2019

244 bytes removed ,  23 March 2019
→‎Octave Package management: Refactor with ideas from https://savannah.gnu.org/bugs/?39479.
(Update mentor name)
(→‎Octave Package management: Refactor with ideas from https://savannah.gnu.org/bugs/?39479.)
Line 342: Line 342:
=== Octave Package management ===
=== Octave Package management ===


Octave management of installed packages is performed by a single function, {{codeline|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.
Octave management of installed packages is performed by 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 are:
The planned improvements (see also {{bug|39479}}) are:


* install from URLs
* install and update from repositories (hg and git)
* install and update from repositories (hg and git)
* automatic handling of dependencies
* automatic handling of dependencies
Line 355: Line 356:
* support for multiple Octave installs
* support for multiple Octave installs
* support for system-wide and user installed packages
* support for system-wide and user installed packages
* testing packages (<code>pkg test <package-name></code>)


The main objective of this project is to make {{codeline|pkg}} more user friendly and to make it a tool to foster third party participation in Octave.
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.
{{codeline|pkg}} needs to be more flexible and intelligent when dealing with packages, different verisons and different sources, as well as options on how to build and install the package.
However, the current {{manual|pkg}} also performs some maintenance functions which it probably should not.
There are also advance features of pkg that are useful for testing packages. However, the current {{codeline|pkg}} also performs some maintenance functions which it probably should not.
Instead a package for developers should be created with such tools.
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]).


To do this enhacenment effectively, a refactoring of the current {{codeline|pkg}} code will be needed.
Many of these problems have been solved in other languages.
[https://bitbucket.org/carandraug/octave/commits/branch/pkg This job was started once], but due to diverging and growing specifications, it stalled.  
Familiarity with how other languages handle this problem will be useful to come up with elegant solutions.
In this project we will focus on the most needed features, keeping the requirements to a minimum.  
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.


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 workaround this by is choosing increasingly complex package names that give no hint on the package purpose.
In addition, package names may start to collide very easily. One horrible way to workaround 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 {{codeline|pkg}} would think all this things now, or allow their implementation at a later time. Read the [[OEP:pkg|unfinished plan]] for more details.
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'''
* '''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.
: 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'''
* '''Difficulty'''
: Easy to Medium.
: Medium.
* '''Mentor'''
* '''Mentor'''
: [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco, Sebastian Schöps
: [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco, Sebastian Schöps
Retrieved from "https://wiki.octave.org/Special:MobileDiff/11836"