Re: pkg.m status and question

[Philip Nienhuis]

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