Summer of Code - Getting Started: Difference between revisions

→‎Octave Package management: rename, add a lot more details, and offer to mentor it
(→‎Octave Package management: rename, add a lot more details, and offer to mentor it)
Line 390: Line 390:
'''Possible mentors''': John W. Eaton or Jordi Gutiérrez Hermoso
'''Possible mentors''': John W. Eaton or Jordi Gutiérrez Hermoso


=== Installation of packages ===
=== Octave Package management ===


{{Warning|requires review and mentor}}
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.


We would like to enhance the management of Octave-forge packages from within Octave environment. Currently there is a working (but rather monolithic) function that is used to do the job. The work would be to improve the way Octave interacts with the package server. Since the functionality is already sketched by the current function, the most important skill is software design.
The planned improvements are:


'''Minimum requirements''': Ability to read and write Octave code. Minimal FTP/HTTP knowledge.
* support for multiple Octave installs
* support for multiple version packages
* support for system-wide and user installed packages
* automatic handling of dependencies
* more flexibility on dependencies, e.g., dependent on specific Octave build options or being dependent in one of multiple packages
* management of tests and demos in C++ sources of packages
* think ahead for multiple
* easily load or check specific package versions


'''Difficulty''': Easy
The current {{codeline|pkg}} also performs some functions which probably should not. Instead a package for developers should be created with such tools.
 
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. 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.
 
'''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''': Easy to Medium
 
'''Mentor''': Carnë Draug


== Image Analysis ==
== Image Analysis ==