|
From: Robert D. <rob...@gm...> - 2022-09-15 15:19:27
|
On Wed, Sep 14, 2022 at 6:50 AM Stavros Macrakis <mac...@al...> wrote:
> However, I'm pretty sure that most of our users are not software developers, and not familiar with git or github. If the code and documentation are maintained on github, they need to be made available to our users as if they were "native" parts of Maxima; otherwise anything contributed to github might as well not exist.
>
> I don't think that would be hard. We could, for example, extend load so that it accepts addresses on github, e.g., load("github://maxima-packages/sdemarre/diophantine_system/diophantine_system.mac").
Some time ago I created a proof of concept of a system to manage
package dependencies via Quicklisp (https://beta.quicklisp.org),
including a mechanism for loading a package from a remote source; see:
https://github.com/robert-dodier/maxima-asdf
So this is now possible:
install_github ("username", "reponame", "branchname");
which retrieves all the stuff in https://github.com/username/reponame
on the branch named branchname (typically "master").
There are deficiencies. (1) It retrieves everything in the repo; there
isn't a way to get just a certain folder. (2) Quicklisp, last time I
looked, didn't have a way (not that I could figure out, at any rate)
to say "Load the most recent version" if multiple versions of a
package are present in an installation. (3) ASDF which is used by
Quicklisp to manage dependencies locally doesn't work with GCL; from
my point of view this is a motivation to discontinue the use of GCL
with Maxima, since managing packages is an important goal.
> Discovering the existence of such a package is the next hurdle. It would be nice to have an organized catalog of such contributions.
Well, I wonder what's possible here. One approach is to piggyback on
an existing package repository such as Quicklisp, however, that
requires effort on the part of the package author over and above just
writing the package. Another is to establish a tag or label which
could be attached to a package to advertise that it's a downloadable
Maxima package, however, that's going to be specific to the hosting
system, e.g. some label on Github won't apply to packages on another
hosting system. Yet another is to put packages all in the same place,
as it is now for example with
https://github.com/maxima-project-on-github/maxima-packages, however,
that doesn't cover packages anywhere else.
I'm trying to steer towards putting the responsibility for package
management on the package authors, and away from putting it on the
Maxima development team. I know that package authors are often just
interested users of Maxima without much background in software
development, and for them any additional steps to publish a package
are speed bumps. Well, if not the package authors, then who is going
to do it -- who is going to write the documentation, unit tests,
respond to questions and bug reports, update the published package?
A kind of far-off ideal is that the ecosystem of add-on packages would
be much larger than Maxima itself, as it is, e.g., with R. I know
we're a long way from that, but I am trying in part to make that ideal
possible.
FWIW
Robert
|