Skip to content

wrapper: expose appName in mnw via config.vim.appname#1634

Draft
NotAShelf wants to merge 1 commit into
mainfrom
notashelf/push-qqwxqywxrrzq
Draft

wrapper: expose appName in mnw via config.vim.appname#1634
NotAShelf wants to merge 1 commit into
mainfrom
notashelf/push-qqwxqywxrrzq

Conversation

@NotAShelf

Copy link
Copy Markdown
Owner

Fixes the hardcoded appname in the build wrapper. I've noticed that the way we set wrapper options is a bit... messy. We have vim.build, but it's used only for finalPackage. I'd like to establish a naming convention with @horriblename, @snoweuph and @Soliprem so this PR can be repurposed as a general-purpose wrapper refactoring one. Alternatively we should allow additional args to be passed to mnw. Maybe @Gerg-L can chime in on that. Recursive merge? Just //?

Signed-off-by: NotAShelf <raf@notashelf.dev>
Change-Id: I993291328809699680c4765ea6313d996a6a6964
github-actions Bot pushed a commit that referenced this pull request Jun 11, 2026
@github-actions

Copy link
Copy Markdown

🚀 Live preview deployed from 7fca440

View it here:

Debug Information

Triggered by: NotAShelf

HEAD at: notashelf/push-qqwxqywxrrzq

Reruns: 3105

@horriblename

Copy link
Copy Markdown
Collaborator

this PR can be repurposed as a general-purpose wrapper refactoring one. Alternatively we should allow additional args to be passed to mnw.

the easiest solution is to just create a vim.build.mnwOpts and pass that to mnw to get the finalPackage, though I'm not sure what's worth exposing and what's not

in other news, I should swap vim.lazy.packages to use https://gerg-l.github.io/mnw/options.html#plugins.optAttrs and lift the stupid "attr name must equal package name" restriction

@snoweuph snoweuph left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this.
just misses some changelog xD

@Gerg-L

Gerg-L commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

why would you need a changelog entry for a new feature?

@Gerg-L

Gerg-L commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Alternatively we should allow additional args to be passed to mnw. Maybe Gerg-L can chime in on that. Recursive merge? Just //?

@NotAShelf
do it as a submodule under mnw.*
consume this file:
https://github.com/Gerg-L/mnw/blob/master/modules/options.nix
handle assertions: https://github.com/Gerg-L/mnw/blob/0871dbf63a53610c95db04439ed8ea4d6ec9c160/modules/common.nix#L21-L25
then pass the end result to mnw.lib.uncheckedWrap

should just work

the other option would be to convert nvf into a mnwModule and leave the current mnw options as-is and just wrap the mnw functions/modules with injecting nvf into them

@snoweuph

Copy link
Copy Markdown
Collaborator

why would you need a changelog entry for a new feature?

Because an Addition is also a change.
Like 80% of the 0.9 release is additions

@NotAShelf

Copy link
Copy Markdown
Owner Author

consume this file:
Gerg-L/mnw@master/modules/options.nix

seems a bit annoying to do tbh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants