informatimago
commented
3 years ago First point
How about using generics and classes for the primary system to allow the user to hook in to the ergo process
ergo:compile designator [function]
ergo:load designator [function]
ergo:test designator [function]
ergo:run designator [function]
The could all be generics instead of normal functions, or at least the core functionality. I know it is just a specification, but I think if you start from a foundation of using classes with generics you will be able to create a highly customizable system.
This represent the user interface, commands you'd type at the REPL. They could indeed be generic functions, but in any case, they will have some very ad-hoc parsing of the arguments. For example, for most of them the argument will be optional, and set a current project used by the following calls. Basically:
(defun ergo:foo (&optional designator) ...)
;; or
(defun ergo:foo (&rest arguments) (ad-hoc-parsing arguments) ...)so we cannot make thosegeneric functions really.
On the other hand, the internals will use CLOS and generic functions a lot, to be extensible.
Second
Perhaps you could initially limit the scope to a git/hub/lab/ea dependency and build tool, rather than providing the ability to fork etc, because most Lisp users are also Emacs users are well versed with Magit, as I assume you know, this is a fantastic tool for handling any sort of complexity with a single git project.
Totally agree, I don't have the resources to over-engineer it anyways. On the other hand, I actually don't know the features of magit, so I don't know if some ideas I have would duplicate.
I'd imagine a use case such as:
(ergo:load foo/bar) ; clone github/foo/bar, compile, load
;; find a bug
(ergo:fork [foo/bar]) ; fork the repo on github with preconfigured account; update project
--> github/myself/bar ; and change the remote
(ergo:where-is [myself/bar]) ; shows the directory/cd/*default-pathname-defaults*
(ergo:edit file.lisp)
(ergo:load [])
(ergo:commit -a -m "...")
(ergo:push [])
(ergo:merge-request)
(ergo:pull-request)
(ergo:pull)ie. the idea would be to make it very easy, starting from "read-only" repositories (dependencies) of a project, to get a writable repository to patch it and send the modifications upstream.
Currently when we find a bug in some source, we have to find the actual upstream repository and commit (thanks to quicklisp dropping the info), then we have to fork the repository on the github web, then we have to clone that repo locally, then we have to mess with quicklisp or asdf configuration to point to that local repo, reload, debug and edit the code, commit from the shell (or with magit), push, and make a PR on the web. Add in posting an issue, creating a branch, etc. This is a lot of manual steps, using different command environments (the web, the shell, or magit or others), that I want to streamline, with a few simple command available at the REPL.
That said, some of those ergo commands could just open a browser page on the github/gitlab feature. For example I image a few commands to browse issues, if we want to comment on an issue, (ergo:issue-comment) could just open the link it in the browser. That said, this is not the core of ergo, just the icing on the cake that will be implemented possibly eventually; we'll see what's ergonomic or required by the users then.
First point
How about using generics and classes for the primary system to allow the user to hook in to the ergo process
ergo:compile designator [function]
ergo:load designator [function]
ergo:test designator [function]
ergo:run designator [function]
The could all be generics instead of normal functions, or at least the core functionality. I know it is just a specification, but I think if you start from a foundation of using classes with generics you will be able to create a highly customizable system.
Second
Perhaps you could initially limit the scope to a git/hub/lab/ea dependency and build tool, rather than providing the ability to fork etc, because most Lisp users are also Emacs users are well versed with Magit, as I assume you know, this is a fantastic tool for handling any sort of complexity with a single git project.
I am just spit balling, but I think the project is a good idea. Thanks.