Re: pkg.m status and question

[Philip Nienhuis]

Mike Miller wrote:
> On Tue, Jan 07, 2020 at 18:18:01 +0100, Philip Nienhuis wrote:
> > I suppose that you refer to the output of the pkg.m function, not so much
> > the contents of the octave_packages files, right?
>
> Yeah, I am only talking about the user interface of the "pkg" function,
> not any internal details.

<snip>

> > 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?
>
> My use case is for simple package metadata lookups to be as simple as
> possible. I maintain the Pythonic package on GitLab. I want it to be
> very easy for a novice user to get URLs such as the git repository, the
> issues page, the user manual, and the wiki from a "pkg" command. For
> example
>
>      pyinfo = pkg ("list", "pythonic");
>      web (pyinfo.url)
>      web (pyinfo.issues)
>      web (pyinfo.wiki)
>      system (['git clone ' pyinfo.repo]);
>
> This would work today, though with a '{1}' added on the "pkg" command,
> ideally that can go away.

So pyinfo needs a cell rather than a struct array, right?

Anyway, that use case seems valid enough for me :-) Thanks for that 
information.
I myself never use pkg.m's output args so this info helps quite a bit.

> > IMO any user who needs to access pkg.m's output should be proficient enough
> > to grasp nested data structure.
>
> I disagree, I think the output is part of the user interface, and as
> such it should be designed to be as clear, simple, and useful to all
> users as possible. If it's not clear, simple, and useful, then why
> return it at all?

With me that immediately raises the question of why "pkg describe" 
returns such horrible (but complete) output. Who/what uses it?

> The overall direction I want to see is for packages and package
> repositories to become more flexible, and for the packaging commands to
> facilitate that flexibility.
>
> Ultimately, I would like to see packaging commands that help users
> install packages from external web, git, or hg hosting sites, update
> those packages automatically, point their web browser at the docs,
> switch to a development snapshot and back to the latest release, and so
> on.
>
> IMHO, a big part of that is allowing package maintainers to add their
> own metadata to the DESCRIPTION and providing easy access to those
> metadata, to experiment with well before they become standardized.

Thanks for this, it gives some welcome grip on what people want from pkg.m.

In comment #18 of bug #57522 I wrote something that may help:
Try to do away with the package databases. All info is already in the 
DESCRIPTION files in the PACKINFO subdirs, and loading states are in the 
path. Generating required info for pkg.m operations can be done on the 
fly and there is less chance for it to be outdated. Parsing and 
validating the DESCRIPTION file into programmatically more manageable 
bits and pieces in PACKINFO/ would facilitate this.

Philip