Lots of hard dependencies?

[a12l]

When I tried to install rigpa using Borg I'd to install all of these dependencies

• ace-window
• avy
• beacon
• buffer-ring
• centaur-tabs
• dash
• dynaring
• evil
• git-timemachine
• ht
• hydra
• ivy
• lithium
• parsec
• powerline
• s
• transpose-frame

to get rigpa to build. Some of them are transitive (hard) dependencies, but most of them are hard dependencies to build rigpa.el. I haven't looked at the code, but based on the README it sounds like several of these should be alternatives to each other, e.g. evil; hydra; lithium; etc.

It is intentional that you need all these dependencies installed to be able to build and use Rigpa? Or should some, or all, of these be soft dependencies?

[a12l]

Should add that I've manually added Rigpa as a submodule to my config, so it's 2744e556903fb3becb926551f6248645b2a7763b (current HEAD) that I'm trying to build.

[countvajhula]

Hi, yes, good call, and thank you for enumerating these for future reference. I believe these are currently hard dependencies, although I agree most of them should be soft dependencies. If you think there could be some small changes (e.g., using (require <dependency> nil :no-error)) that would address this without issue if the dependencies are missing, I'm happy to consider a PR (though I doubt it's that simple).

For a long term solution: We could think of Rigpa's architecture on two levels --- the first is the core functionality, supporting the notion of modes, reflection, representing modal structures like towers, and so on. The second is specific modes for specialized purposes.

For the core functionality, only a few of the "modes" are needed, e.g., buffer mode and line mode are likely to be part of this core. I would expect this core to have few dependencies, just on packages like lithium (the modal interface provider), dynaring (to support ring topologies like #19, which are intuitive and are already pervasively used in both Emacs and in Rigpa), and buffer-ring (to support Buffer mode).

The higher level aspect is specialized modes, of which there are many --- symex mode (symex), history mode (git-timemachine), tab mode (centaur-tabs), etc. I would like these modes to ideally reside in separate packages, following the composable package architecture used by the Symex package. This would allow Rigpa to be maintained in one project repo, but still be provided as multiple distinct packages, and users could install precisely what they need without getting a ton of dependencies the way you noted above.

I believe that would address your concern more satisfactorily. Wdyt?

Please be aware, though, that at the moment I'm taking a break from Emacs work to write a children's book about my cat, Ferdinand. My next target with Rigpa would be to get #19 merged, and I could get to this after that, but I don't know when that would be.

[a12l]

Please be aware, though, that at the moment I'm taking a break from Emacs work to write a children's book about my cat, Ferdinand.

My condolences. He seems to have been a lovely cat! We have two lovely short haired orientals who are very social :)

I believe these are currently hard dependencies, although I agree most of them should be soft dependencies. If you think there could be some small changes (e.g., using (require <dependency> nil :no-error)) that would address this without issue if the dependencies are missing, I'm happy to consider a PR (though I doubt it's that simple).

I've almost no experience writing elisp, so I'll most probably not be able to make any such contributions.

For a long term solution: We could think of Rigpa's architecture on two levels --- the first is the core functionality, supporting the notion of modes, reflection, representing modal structures like towers, and so on. The second is specific modes for specialized purposes.

For the core functionality, only a few of the "modes" are needed, e.g., buffer mode and line mode are likely to be part of this core. I would expect this core to have few dependencies, just on packages like lithium (the modal interface provider), dynaring (to support ring topologies like #19, which are intuitive and are already pervasively used in both Emacs and in Rigpa), and buffer-ring (to support Buffer mode).

The higher level aspect is specialized modes, of which there are many --- symex mode (symex), history mode (git-timemachine), tab mode (centaur-tabs), etc. I would like these modes to ideally reside in separate packages, following the composable package architecture used by the Symex package. This would allow Rigpa to be maintained in one project repo, but still be provided as multiple distinct packages, and users could install precisely what they need without getting a ton of dependencies the way you noted above.

I believe that would address your concern more satisfactorily. Wdyt?

It sounds like that would address the issue, and would be a great solution!

My next target with Rigpa would be to get #19 merged, and I could get to this after that, but I don't know when that would be.

No worries, I'm just testing out Rigpa to see if it's something that fits me. :)