[Top][All Lists]

[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: Wed, 8 Jan 2020 21:34:36 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

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.


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

     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

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.


reply via email to

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