Closed 80aff123-9163-4f3e-a93d-4a2f35af9be1 closed 3 years ago
Thanks, (in-package :nyxt)
helped and everything seems fine now. @ccao001 please try out the new extension-system, I hope it works the way you wanted! If something's the bother, open an issue in the repo.
I suppose this issue should be closed now?
Almost, I would suggest we find a way to reference your repository in the interim. I liked the idea of utilizing a repository with submodules for this purpose. @Ambrevar shall it not be an OK stopgap solution until our quickdist is ready?
That or the wiki we talked about recently.
@kssytsrk I've sent a fix there: https://github.com/kssytsrk/invidious-handler/issues/1
I also suggest we namespace the Nyxt extensions. For instance, instead
of the invidious-handler
package we would have
nyxt/ext/invidious-handler
.
Thoughts?
Why would we like to namespace things?
This would help the user or the hacker to tell what's a Nyxt extension from what's not just by looking at the symbol package.
In the user configuration, it makes it easy to tell what depends on something external or not.
Take Emacs: When a package is "require"d, it imports a bunch of symbols. After this point, it's hard to tell what's vanilla Emacs from what is not.
Even with Common Lisp packages, we can't obviously tell what's vanilla Nyxt unless you know the default Nyxt packages by heart (chanl, bordeaux-threads, etc.).
Sorry for the slow reply, was kinda busy. I don't have a lot of experience with asdf and packaging, so I don't seem to understand how to namespace things and haven't really found any docs on that (aside from "The Complete Idiot's Guide to Common Lisp Packages", but it doesn't mention namespacing). This is what I am doing:
(invidious-handler.asd)
(asdf:defsystem nyxt/ext/invidious-handler
...)
(package.lisp)
(in-package :nyxt)
(uiop:define-package :ext/invidious-handler
...)
(invidious-handler.lisp)
(in-package :nyxt/ext/invidious-handler)
...
In my init file, I try to load it with (asdf:load-system :nyxt/ext/invidious-handler)
, but I get "Could not load the init file: Component :EXT/INVIDIOUS-HANDLER not found" when starting Nyxt. I sense that something is really wrong with my definitions of system and package, but can't really pinpoint what. Could you provide any pointers on this?
kssytsrk notifications@github.com writes:
(package.lisp)
(in-package :nyxt) (uiop:define-package :ext/invidious-handler ...)
The keyword passed to define-package (or defpackage) must be "absolute", so if you want to define the :nyxt/ext/invidious-handler package, you need to specify it completely:
(uiop:define-package :nyxt/ext/invidious-handler ...)
Thank you. But for some reason I still get "Could not load the init file: Component :EXT/INVIDIOUS-HANDLER not found" even though I've checked and I don't use :EXT/INVIDIOUS-HANDLER anywhere.
In the .asd maybe?
Nope, my code for .asd is as follows:
;;;; invidious-handler.asd
(asdf:defsystem nyxt/ext/invidious-handler
:serial t
:version "1.0.0"
:description "A redirector from Youtube to Invidious."
:author "kssytsrk"
:license "GNU General Public License v3.0"
:depends-on (:nyxt
:dexador
:cl-json)
:components ((:file "package")
(:file "invidious-handler")))
I'm not sure, does Lisp recompile systems when starting Nyxt? If it didn't everything would make sense
It recompiles it if it changed. How do you build Nyxt?
Well, I'm running it from a compiled binary, but the extension is just loaded from the init file so I don't suppose I have to recompile the whole browser to make changes to an extension?
Try not using nyxt/ext but nyxt-ext instead.
Still doesn't work. For some reason any package that has slashes in system/package name won't load, I even thought it was because of asdf expecting the .asd file here "~/common-lisp/nyxt-ext/invidious-handler/nyxt-ext/invidious.handler.asd" but that didn't work either.
The .asd can be left at the root.
Can you push your attempt on a non-master branch so that I can investigate?
Okay, I just pushed kssytsrk/invidious-handler@f12aefa.
Sorry for the late answer.
We've just created the load-after-system helper which should help with loading extensions. https://github.com/atlas-engineer/nyxt/commit/0c32d100e545200d666207e4db2a37e44c7394ba
I'll looked into your issue as soon as possible.
Thanks, just updated the readme with load-after-system.
@Ambrevar
I make a file called extension.org
where we can list all community extensions for now, OK?
Yes!
Thanks! Let's keep this to a separate issue, we've polluted this one for way too long already ;)
Actually forget #1011, see #966 instead.
@kssytsrk I've finally taken the time to look at the issue! (Sorry for the delay...)
- (setf invidious-handler:*preferred-invidious-instance* (nyxt-ext/invidious-handler::object-string instance))
+ (setf nyxt-ext/invidious-handler:*preferred-invidious-instance* (nyxt-ext/invidious-handler::object-string instance))
The .asd file must have the name of the main system, here "nyxt-ext". So it must be named "nyxt-ext.asd".
You can't define a subsystem (when the name contains a "/") without defining the main system. So if you define the dummy system:
(asdf:defsystem :nyxt-ext
:description "Forward system declaration for Nyxt extensions.")
it will work.
The problem is that this nyxt-ext
system will clash with that of other extensions. So it should be defined in Nyxt, not in invidious-handler.
Shall we include the nyxt-ext
system in our ASD then?
There is an alternative: instead of prefixing the system, we could leave it as it is (here invidious-handler
) and only prefix the package name. It's a bit simpler.
The main drawback is that when the user loads a system they won't be able to immediately tell whether a Nyxt extension or not.
Compare:
(load-after-system :nyxt-ext/invidious-handler)
with
(load-after-system :invidious-handler)
The package symbols remain properly prefixed with nyxt-ext/invidious-handler however.
Let's include nyxt-ext in our ASD, yes :-)
People typically also expect the package and system naming to be consistent, so we will also benefit in that way.
OK!
Done!
Okay, thanks for checking the code. Just pushed kssytsrk/invidious-handler@66c0115, but it still doesn't really work (errors out with Could not load the init file: Component "nyxt-ext" not found, required by #<SYSTEM "nyxt-ext/invidious-handler">
even though the version of Nyxt I use was pulled yesterday and I can see the system definition in the source). When I define nyxt-ext in invidious-handler's nyxt-ext.asd, it works fine though.
Indeed, this can't work. The main system needs to be defined in the same .asd as the extension. Oh well...
So instead of dealing with subsystems, I suggest we follow the convention of prefixing system names with, say, "nx-". This is what Stumpwm does:
https://github.com/stumpwm/stumpwm-contrib https://github.com/njkli/stumpwm-weather
A "/" in the package name still works though, but do we want it if we don't use it in the system name? Out of consistency, maybe not.
So what about "nx-invidious-handler" both for the package name and the system name?
We also need to think about extensions that may use multiple packages, e.g. multiple modes. These extensions would use a slash in their names, so that would look like
nx-foo/first-mode nx-foo/second-mode
Thoughts? @jmercouris
I think that is a good set-up. Let's do it!
This is cool. I've seen something similar few days ago. Makes me wonder if instead of an Invidio instance only handler a FreeStance handler? Twitter(Nitter), Instagram(Bibliogram), Reddit(Teddit) and ofcourse Invidio instead of YouTube. I've no coding skills, im just throwing that around.
This is great! Thanks for suggesting this, didn't know about it! Indeed, looks like Nyxt's invidious extension could be generalized.
Teddit is really cool in particular! :)
Oh, I thought about doing something similar a few days ago. After looking into it for a bit, though, I'm not sure what's the best way to implement it. Nitter, Bibliogram and Teddit don't have an API that returns the list of instances, neither do they document their "health". Anyway, all of them have official instances (Nitter - nitter.net, Bibliogram - bibliogram.art, Teddit - teddit.net) that seem to work fine, should the handler just redirect to them? Another option would be hardcoding the lists of instances and choosing a random one, I guess.
Also, should I rename invidious-handler to nx-invidious-handler now? @Ambrevar
Yes, the name should be nx-invidious-handler. We think a consistent naming scheme will aid in discoverability, much like how emacs plugins are often 'el-xyz'.
I thought you guys would probably like that ;) Then let me share this as well.(Not an instance, im just sharing) Available since yesterday. RAMBLE is a Reddit-like accessible over the clearnet, Tor, I2P and Yggdrasil. Enjoy!
It's all done! I renamed the repo and the package to nx-freestance-handler and added the redirectors to Teddit, Bibliogram and Nitter. @danrobi11 hope you find it useful!
The configs shouldn't break much aside from the fact that everyone has to replace "invidious-handler" package name with "nx-freestance-handler".
Thank you for the update! I think it is OK to close this issue for now, if something comes up again, please feel free to reopen!
hope you find it useful!
@kssytsrk Thank you much!
How could I add a function that with a single keyboard shortcut opens the modeline and redirects me from
youtube.com
to choose amongst one of several online invidious instances?I would like the modeline to sort the instances by current health of the site. See here or the
dailyRatios
andweeklyRatio
json fields below for an example of what I mean about site health.Any help or suggestions are greatly appreciated! A version of this program for online peertube instances would be cool too.
JSON code showing Invidious Instances as of Today: