Re: pkg.m status and question

[Mike Miller]

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.

The existence and format of the "octave_packages" file is an entirely
internal technical detail. In fact, it's easy to imagine a "pkg"
implementation that doesn't have this file at all.

> 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.

Sure, the "depends" and "provides" fields are complex, but I think it's
somewhat necessary, since other "pkg" commands parse that information. I
think both of those fields could be more easily converted to ordinary
struct arrays, since these contents do have fixed formats.

> 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.

> 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?

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 your interest,

-- 
mike

signature.asc
Description: PGP signature