[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkg.m status and question
From: |
Philip Nienhuis |
Subject: |
Re: pkg.m status and question |
Date: |
Tue, 7 Jan 2020 18:18:01 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0 |
Mike Miller wrote:
On Mon, Jan 06, 2020 at 23:44:24 +0100, Philip Nienhuis wrote:
We need a basic struct with all required fields that are of the same type
for all packages.
All fields that are heterogeneous (not required for each package and/or not
used by the package manager) go in substructs or cell arrays in a dedicated
field of the main struct. That way we move heterogeneity from the outside
wrapper into a much less prominent location inside, out of the way of
regular package manager operations.
This seems unnecessarily awkward for the task at hand. Are you
suggesting a package description struct might be accessed like this
d = pkg ("list", "foo")
d.name
d.version
d.maintainer
d.extensions
d.extensions.citation
d.extensions.wiki
d.extensions.("bug-tracker")
or like this
for i = 1:length (d.optionalfields)
d.optionalfields{i}.keyword
d.optionalfields{i}.value
endfor
Does it really seem like a worthwhile tradeoff to introduce a new nested
struct or array of optional properties just to have a fixed base
structure definition that can be stored in an array? No, that seems even
more complicated to me. This is software, after all, not a packet
protocol.
>
> I guess internally you can store it however you feel is best, but the
> user should have access to an easy flat structure that contains all of
> the package metadata, both required and optional, as it is now.
I suppose that you refer to the output of the pkg.m function, not so
much the contents of the octave_packages files, right? AFAIU the latter
aren't meant to be edited so can be v7 formats as well and their
internal setup shouldn't matter to the average user.
Did you look at e.g., 'out = pkg ("describe")'?
The result is another seemingly (to me) needlessly complicated
datastructure: a cell array of structs, each of such a struct again
containing some fields comprising cell arrays of structs.
E.g., a small part of the zeromq entry of above command's output in my
mxe-octave installation:
:
[1,48] =
scalar structure containing the fields:
name = zeromq
version = 1.5.0
description = ZeroMQ bindings for GNU Octave
depends =
{
[1,1] =
scalar structure containing the fields:
package = octave
operator = >=
version = 4.0.0
}
provides =
{
[1,1] =
scalar structure containing the fields:
category = ZeroMQ overview
functions =
{
[1,1] = zeromq
}
:
:
Your wish to keep a flat data structure triggers my curiosity: what is
the use case of having a flat output structure? Why is that needed?
IMO any user who needs to access pkg.m's output should be proficient
enough to grasp nested data structure.
Anyway, no fear, I'm not planning to start hacking deeply into pkg.m
soon. I'm just investigating, ATM just out of curiosity.
When and if the time comes it's easy to leave the output package info
cellstructs as they are and add translation routines from a
programmatically more manageable data struct.
Philip