[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pkg.m status and question

From: PhilipNienhuis
Subject: Re: pkg.m status and question
Date: Fri, 10 Jan 2020 06:17:36 -0600 (CST)

Juan Pablo Carbajal-2 wrote
>> On Mon, Jan 06, 2020 at 23:34:06 +0100, Juan Pablo Carbajal wrote:
>> > Int he direction of making pkg handling better, we should have a
>> > uniform structure for the DESC file with all possible fields, any DESC
>> > file that does not fill one leaves the default value of NA.
>> I humbly suggest that the package description struct should have some
>> number of required fields, but any number of user-defined optional
>> fields that can be added to the package as needed. There is no way to
>> define all possible fields. That's the way it works now, please don't
>> make it more restrictive.
> If user can add arbitrary fields, then there is no standard.
> My proposition is that we manage to get this flexible enough that if
> new fileds are good ideas, the stadard can be extended.
> We can also always have a "UserDefined" field in the basic structure
> that collects all user define fields that are not part of the
> standard. This goes close to the idea of Philip.
> Functions that process this information need to process the standard
> fields, but can do whatever they wish with th einfo inside
> "UsedDefined".
> This gives a lot of uniformity in the code, and probably the
> identification of lots of boiler plate sections and good practises.

It turns out that the only fields that are really used for pkg.m operations
(viz. un-/installing, un-/loading) are "name", "release", "depends", "dir"
and "archdir".
All other fields are only parsed from the DESCRIPTION file and put into the
package's cellstruct item and they are returned verbatim in case of "pkg
describe" and "pkg list".


Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]