Bug 277788 - editors/vim: make optional language bindings pkg flavors
Summary: editors/vim: make optional language bindings pkg flavors
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Adam Weinberger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-18 16:30 UTC by Matt Simerson
Modified: 2025-01-10 13:50 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (adamw)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Simerson 2024-03-18 16:30:11 UTC
# pkg install vim
New packages to be INSTALLED:
	libffi: 3.4.4_1
	mpdecimal: 2.5.1
	python39: 3.9.18_1
	vim: 9.1.0158
	xxd: 9.1.0158

The process will require 161 MiB more space.

161 MiB just for vim?

What I want and expect is the console flavor of vim with syntax files and the basic goodies that make vim better than vi. Colors. Syntax highlighting. Those niceties are stripped from vim-tiny. What I do NOT want or expect is bundling 100+ MiB of language interpreters just to get vim. By all means, have packages pre-built for popular options, but that shouldn't be the default. Users wanting a bundled language interpreter should expect to specify a flavor, such as vim-python, vim-perl, or vim-lua.
Comment 1 Adam Weinberger freebsd_committer freebsd_triage 2024-03-18 18:14:26 UTC
Yeah, vim-tiny is not a console-only vim flavor, for sure; it exists for a very specific use case and is the wrong choice for most people.

The problem is that vim has to be built with each language support, and each of them requires the dependency at build time. Some of the languages support dynamic linking for runtime, but the dynamically-linked language bindings have historically behaved differently.

I surveyed the user base a few times (maybe 2-3 years ago?) and it was clear that a significant number of people used python-based plugins, and so I kept the python dep. It felt safe, as I figure many people have python installed anyway (and it's brought in by many other packages as well).

So, in summary: I agree with you, dependencies suck, I can't just package language bindings separately, and bundling python was intentional.
Comment 2 Matt Simerson 2024-03-18 19:14:42 UTC
Thanks Adam for responding, and quickly too!

"I can't just package language bindings separately"

In reading through the release notes of vim, I got the impression that port flavors was an answer to this type of choice. So I searched and found https://docs.freebsd.org/en/books/porters-handbook/flavors/, which seems to indicate to me (not a port author) that flavors are *intended* for exactly this type of situation.

Is there some limitation on pkg versions or ... can you help me understand why a port flavor wouldn't work here? Even if a substantial number of people want python bindings, there are a lot of us with a lot of reasons (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=python) why we don't want python installed. It seems reasonable for users wanting python bindings to ask for it with vim-python. I can understand bundling it by default with fat versions (gtk/x11/motif).

If making 'vim' install *only* vim isn't possible, how about a special flavor (again) that is vim and nothing else? Suggestions: vim-console, vim-lite, vim-no-deps, or vim-no-options.
Comment 3 Adam Weinberger freebsd_committer freebsd_triage 2024-03-18 19:36:38 UTC
(In reply to Matt Simerson from comment #2)

Because building with python support alters the vim binary. We can't use subpackages because it alters the vim binary itself.

And I can't make vim-console, vim-console-python, vim-console-ruby, vim-console-python-ruby-lua, vim-console-ruby-lua, etc. etc. etc. flavors.
Comment 4 Sudgers 2024-04-26 03:14:25 UTC
(In reply to Matt Simerson from comment #2 Thanks Adam for responding, and quickly too!

"I can't just package language bindings separately"

In reading through the release notes of vim, I got the impression that port flavors was an answer to this type of choice. So I searched and found https://docs.freebsd.org/en/books/porters-handbook/flavors/, which seems to indicate to me (not a port author) that flavors are *intended* for exactly this type of situation.

Is there some limitation on pkg versions or ... can you help me understand why a port flavor wouldn't work here? Even if a substantial number of people want python bindings, there are a lot of us with a lot of reasons (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=python https://bloxdio2.com bloxd io) why we don't want python installed. It seems reasonable for users wanting python bindings to ask for it with vim-python. I can understand bundling it by default with fat versions (gtk/x11/motif).

If making 'vim' install *only* vim isn't possible, how about a special flavor (again) that is vim and nothing else? Suggestions: vim-console, vim-lite, vim-no-deps, or vim-no-options.)


I also think like you!
Comment 5 Siva Mahadevan freebsd_triage 2024-06-18 18:08:59 UTC
Is there a reason why defining normal port OPTIONS won't work for this use case? Then you can add various configure args with XXX_CONFIGURE_ON and XXX_CONFIGURE_OFF to modify the optional dependencies.
Comment 6 Adam Weinberger freebsd_committer freebsd_triage 2024-08-26 14:34:15 UTC
After much, MUCH thought, I’ve changed my mind; you all have convinced me.

I think the default vim package needs to include python (I ran two surveys and got a significant number of users who say they use the python bindings).

But, let’s add a new flavor that’s just console vim without the python bindings. 

That said, I need help from you all on coming up with the right name.

Rather than calling it nopython, the name should indicate that it has no bindings of any sort. But the name also needs not to suggest that it still does all the normal things when *editing* files. It’s just the bindings for plugins written in other languages that aren’t present.

If you can help me come up with the right name, I’ll get this new flavor added.
Comment 7 Adam Weinberger freebsd_committer freebsd_triage 2024-08-26 14:36:38 UTC
Fixing a typo:

But the name also needs not to suggest that it breaks *editing* files. It needs to indicate that it has no bindings, but doesn’t look scary for people who don’t know what bindings actually indicate.
Comment 8 Matt Simerson 2024-08-26 20:03:34 UTC
The only reason naming a "vim port without X bindings" is difficult is because the obvious name for such a port is already taken: vim. That's so clean and obvious, as is asking for a vim with bindings such as vim-python, vim-gtk, or vim-lua.

Presently, for anyone who attempts to install vim, sees the bundled python and doesn't want it, and then does a `pkg search vim`, the obvious name for a vim without python bindings is: vim-nopython. Which you've already ruled out.

The next best option is probably vim-lite, with the description, "Improved version of the vi editor (console flavor, no options)." And yes, no options also means no XXD nor NLS. Clean and simple. As if you were aiming for a version of vim in which there's no obvious answers to the question, "why isn't 'vim' the version of vi bundled with FreeBSD?"
Comment 9 Melissa Joyce 2025-01-10 13:50:25 UTC
When building or packaging Vim, providing optional language bindings as package flavors is a common approach used in Linux distributions and other software systems. This allows users to customize Vim installations based on their specific needs without including unnecessary language support or dependencies.
https://nbiclearancesonline.ph/