Editing Code sprint: pkg.m

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

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 6: Line 6:
* [[User:KaKiLa|KaKiLa]] 07:34, 2 October 2012 (PDT)
* [[User:KaKiLa|KaKiLa]] 07:34, 2 October 2012 (PDT)
* [[User:Carandraug|carandraug]] 06:47, 3 October 2012 (PDT)
* [[User:Carandraug|carandraug]] 06:47, 3 October 2012 (PDT)
* [[User:JordiGH|JordiGH]]
* [[User:Carlo|cdf]]


== Clone Carnë's repository ==
= Schedule =
https://bitbucket.org/carandraug/octave/changesets/tip/..bookmark%28%22pkg%22%29
 
= Parsing arguments passed to pkg =
One of the most intimidating parts of pkg.m is the monstrous way the parsing of arguments is done. The current mayhem is probably due to the natural evolution of the code.
the method use to parse the arguments is based on a flag system.
 
We started cleaning up the parsing of options to give some structure and make pkg.m easy to extend in the future. For this we focus on encapsulation.
 
== Definitions of actions, targets and modifiers ==
A typical call to pkg looks like
 
  pkg install -forge pkg1 pkg2 pkg3 -j4
 
We can identify three types of input arguments
* Action: install
* Modifiers: -forge, -j4
* Targets: pkg1, pkg2, pk3
 
So far we have defined them as follows
* Action: The first input argument and can't start with a hyphen.
* Modifier: Must start with a hyphen.
* Target: Anything that is not an action nor a modifier
 
== Dispatching ==
 
Each action has its own set of valid modifiers and behaves accordingly, that is the function ''pkg'' does not parse targets nor modifiers. Therefore the rôle of the main function ''pkg'' is to call the right action once general sanity checks have been performed.
 
The particular implementation of this dispatch behavior was source of some discussion.
* Using structure
: One way of implementing the dispatch is using structures with fieldnames equal to the action and containing a function handle. [http://agora.octave.org/snippet/5UUz/ Here is an example].
: Some people do not like this because they consider it a weird use of a structure.
* Using ''feval''
: Another way of doing it (and the implemented as of revision 2c16a852bae9 in carandraug's repository) is building a string of the function to call and use ''feval''. [http://agora.octave.org/snippet/ozym/ Here the example]
* Using objects
: Where we have an ''action'' class with fields valid_modifiers and method parse_modfiers. All ''_pkg'' actions inherit the general valid_modifiers and extend them with their own, as well as overloading the parser_modifier method. This gives the maximum flexibility, but since is too much of a change we haven't code it.
 
=== Action functions ===
 
The action functions have the suffix ''_pkg'' in their names. These functions should contain a cell of valid modifiers if they accept any. The function ''parse_target_modifier'' is called to check the validity of the modifiers and to separate them from targets. The cell of valid modifiers can contain regular expressions. This is required since we want to accept modifiers compatible with ''make'' flags (such as -jX for parallel compilation).
 
=== No globals ===
We are trying to avoid global variables at all cost. Everytime a read-only value is needed in several functions, we create a helper function that returns the value.
 
We have to see how we are going to solve the issue with actions like 'global_list' (deprecated, now called 'global_db') that can change the pointer to the file containing the package database.
 
= Desired features =
 
== Reverse autoload function ==
Though is not related with pkg.m, the function autoload can simplify considerably the PKG_* scripts. The idea is to give generate a function that reverses autoload.
 
* Change set [http://octave.1599824.n4.nabble.com/reverse-of-autoload-tt4646746.html committed to mailing list]. [[User:KaKiLa|KaKiLa]] 13:44, 17 November 2012 (PST)


= Objectives =
== Option update should behave as option install ==
== Option update should behave as option install ==
* It should parse a list of packages and maybe the same flags as install  
* It should parse a list of packages and maybe the same flags as install (-auto, -noauto, etc)
* It should not stop updating if a package is not found (i.e. user local package, not in Forge).
 
=== Coders ===
* [[User:KaKiLa|KaKiLa]] 04:42, 1 November 2012 (PDT)
 
== Integrate generate_html into Octave-core ==
* The system used to generate pakage releases should be more closely integrated with the package manager
* Maybe a "pkg release" command possibly with "pkg release -binary" option would be a good interface
=== Coders ===
* cdf
 
== Keep sources in installed packages ==
* "pkg rebuild" should re-generate any .oct files, this would be useful when an Octave update breaks the API
=== Coders ===
=== Coders ===


== Remove -global and -local flags ==
== Remove -global and -local flags ==
* Those flags are have shaky functionality so they should disappear
* Those flags are currently ignored internally anyways so they should disappear
=== Coders ===
=== Coders ===
* Carnë has already a changeset for this
* Carnë has already a changeset for this
== Allow packages to deprecate functions ==
== Allow packages to deprecate functions ==
* Create a system that allows packages to deprecate functions as in core. Possibilities are:
* Create a system that allows packages to deprecate functions as in core. Possibilities are:
Line 112: Line 46:
* <pre>pkg whereis function_name</pre> list the installed packages (loaded or not) that have a function matching the name function_name.
* <pre>pkg whereis function_name</pre> list the installed packages (loaded or not) that have a function matching the name function_name.
* <pre>pkg whereis -forge function_name</pre> list all forge packages that have a function matching the name function_name.
* <pre>pkg whereis -forge function_name</pre> list all forge packages that have a function matching the name function_name.
=== Coders ===
* KaKiLa
Please note that all contributions to Octave may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Octave:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)
Retrieved from "https://wiki.octave.org/Code_sprint:_pkg.m"