Registry etiquette

[elken]

Hi all,

I did try and go through the various docs for an obvious answer but couldn't find one; hence this post. If it's the wrong category/place for such, please redirect me :)

Short version is I really dig mason.nvim and I've had a similar project on my back-burner for Emacs for a while now; so I'm wondering if it would be acceptable to utilize Mason's registry?

As far as I can tell because it's a public API and such technically I can, I just thought I'd raise this first in good faith so it doesn't seem like I'm trying to swipe anything from Mason or compete. If I were to go down this avenue, I would of course make it clear the line of demarcation in terms of where reports should go issue-wise so you don't all get flooded with Emacs-specific queries you maybe won't be able to answer.

And in terms of naming/branding, I'm completely indifferent so if for example you want me to avoid using "mason" in the title to make it clearer there's no direct affiliation that's fine with me. Inversely, if you'd be interested in such a package to exist under mason-org once it gains some stability that'd be fine too.

TL;DR thoughts on other tools sharing Mason's registry

[williamboman]

Hello! One of the reasons of introducing the mason-registry was to make it available for other editors (the registry is Apache 2.0 licensed), so this is definitely very welcomed (and even if it wasn't, it's open source so anyone is free to will it into existence 😄). I didn't expect there to be outside interest to do so for quite some time. There are two things that might prove somewhat difficult in terms of porting it:

1. The registry allows for expressions in various places in the package definition. While I've tried to keep these as language-agnostic as possible, they are still quite tied to Lua syntax. These may prove difficult to translate, you may find the mason.nvim implementation in this module.
2. The platform/target specification & implementation is a bit lackluster at the moment. You may find all the officially supported targets here. Most (if not all) ARM targets that are not specifically arm64 are really just placeholders at the moment. They're very infrequently used in package definitions, and when used it may not be entirely valid. (planning on revisiting this altogether)

I'd recommend studying modules in this directory first, anything around it is mostly auxiliary.

[elken]

Thanks William, I had assumed that I just wanted to make sure :D

1. Yeah I was skimming through that, it seems there's 2 kinds of expressions:

• path.to.a.key which is really easy to resolve
• function | chains of which I'll have to alias functions that already exist (strip-prefix etc)
  That's probably where most of the complexity will be, otherwise it's just maintaining a JSON file and using it to create a UI/manage a contained file system

2. For the most part Emacs can both run in the same places as neovim (arm doesn't have "official" releases for it but the Mac packages have it ported to arm64 and people can always cross compile) and for OS there are built-in predicates for asserting so that combined with uname -m and that at least should just transparently work

I attempted to squeeze some time on this last weekend, so far I have syncing the JSON file so next it'd be tackling parsing. Thanks for the pointers! As for naming I've gone with "toolbelt" for now

[williamboman]

3. For the most part Emacs can both run in the same places as neovim (arm doesn't have "official" releases for it but the Mac packages have it ported to arm64 and people can always cross compile) and for OS there are built-in predicates for asserting so that combined with uname -m and that at least should just transparently work

👍 FWIW, mason.nvim currently uses a combination of :h has() (for OS detection) and uv_os_uname (for arch and sysname [currently only OpenBSD] detection), which maps directly to uname(2) on non-Windows systems.

I attempted to squeeze some time on this last weekend, so far I have syncing the JSON file so next it'd be tackling parsing. Thanks for the pointers! As for naming I've gone with "toolbelt" for now

Sweet, LMK if you have any other questions. Also feel free to use the "mason" name in the plugin, I'd be happy to host it under mason-org (and invite you to the org) in the future when/if it's stable for usage. I need to figure out a way to migrate mason.nvim to the org without breaking everything.

[elken]

Should be what you want in Settings. The redirect should work eg in the case of https://github.com/hlissner/doom-emacs, but there are some caveats

Another option is archive it, push a commit than flags some kind of warning to the user to say "use the new plugin here"