I’m porting an assembler that I think it will be a good addition to HP repo. This comes with its own set of syntax highligting files, including VIM among others. I think it would be a good idea to install these modules with the main assembler as well.
Is there a standard way to check if a package is installed in a recipe (VIM, in this case)?
Assuming VIM is installed, where have I to install/copy/ put those add-ons files?
Let’s say I manually copy these files on a settings dir, what’s happen if the package itself is removed?
I think there are lots of different ways to perform those actions within a bash script. I was wondering if there is a more standard and robust way to do…
I think Vim has a data directory that you can place these files into, i.e. within the package, and Vim will pick them up and use them if it is installed.
No, that doesn’t really make sense. The recipe is run in a chroot where only it’s declared dependencies are available. Then the package is uploaded to the repository.
You have two ways to handle this:
Always include the files in the package. People who don’t use vim will just have unneeded files around. Probably OK if the files are small
Declare a separate _vim package in the recipe (as it is done for example for _devel pacakges for libraries) and put the files there. This way is more modular.
And this is probably the best way to do in general, although not having the possibility to have different descriptions for sibling packages could make things a bit confusing at the end of the day
-There is one package installed already
-you package proof this program is installed
-your package install files to the available directory
Packages are virtual, they hanging in at startup or installation. So you can use the same folders like the other program too, but you need to hanging the files in using a package.
Example
-Package one /boot/system/apps/program1
-Data files /boot/system/apps/program1/data/…
-Package two /boot/system/apps/package2
-use same data folder /boot/system/apps/package1/data/…
If any script is to run after install - either by the user, or at install time (which I do not believe is an option) - it won’t be able to copy files into vim’s install directory, so here you’d be back to $HOME/config/settings/vim
Unless this is a more massive collection than I imagine, I think the separate package is overkill. I guess that leaves you shipping the vim files in your package’s data, and just notifying users where it is if they want it - I think that’s easier for them than being notified they have to go get another package anyway.
A package is like a read-only union filesystem. My picture of what waddlesplash was proposing, that your filesystem and vim’s could both have /data/vim directories, and both packages’ files would appear there, if both were installed; if vim weren’t installed, yours would be alone there, and vice versa. But that’s awkward because the directory depends on the installed vim version. You can’t go in after the fact because they’re read-only, and anyway that would fall apart at the next vim upgrade.
As far as I can see (from “:help vimruntime” and “:version”), the versionned vimruntime is not mandatory. If it does not exist, vim will look in /system/data/vim/runtime instead. So, maybe we could change the way we package vim to use that instead, if it makes things simpler.
This is what I did at the end of the day. It will work until we will stay on the vim8.2 branch.
+1 to repackage vim . But we must put extreme care here I guess. Vim is installed in almost every Haiku installation all around the world. Repackage it will break apart the systems were the users have customized the content of the versioned runtime dir I guess.
…and I’m happy that a so trivial question about a vim addon for a very exotic language generated a so intense debate
Can somebody explain why would anyone package vim plugins?There are vim plugin managers, they can solve the problem.
Packaging won’t actually help to “Regular Joe”, because “Regular Joe” would use StyleEdit instead and the users who uses vim and want to pimp it, knows already where to go to install/remove/change plugins (eg. vim help screen lists the used folders and their paths).
Can maybe understand for extensive plugins like YCM, but in this case would be also nicer to upstream the Haiku related patches so every brave sould could just install it with his favorite vim plugin manager.
I see no point in this but i don’t use vim, so maybe i missed some important aspects.
Ofc, vim is not for the regular user. And ofc, the syntax for 65** assembly is not for the regular user. But this is only incidental.
Relying on the user on manually copy the so-called plugins made available on a package subpath to the proper directories is a valid choice. But it must be documented (in the description?).
It could be the Regular Joe or Jeff Minter, but two linex explaining the procedure should be provided. Let alone to find standard place to put those files for the users to pick them up. This is going to be a subjective task, for the porter, if there’s no a common, defined, way to do so.
What’s the licence for the syntax files? If it comes with a suitable licence, it can be upstreamed.
If not, it can be handled as a Vim plugin, and a Vim plugin manager or the native Vim plugin manager can handle the rest. I don’t see any reason to create another recipe or package.
For any other situation, ~/config/settings/vim should be used.
For what it’s worth, vi has been all I’ve every used on BeOS and Haiku for the last couple decades and then some, and I do fiddle with the vim configuration files (colors on black background need bold fonts to be visible) - but I have never heard of a vim plugin manager. My point being that support for vim is really support for an editor that has been around for half a century, long before vim (which itself has been around for a long time.) Users will typically have learned enough about this particular implementation to serve their purposes, but they’re really here to edit assembly language files or whatever, which may turn out quite well without plugin managers.
Mmmm… I’m planning on moving to Vim as can be the same interface and settings on Silverblue as well as on Haiku. Besides, Vim already has GDScript sintax highlight available, which allows to code Godot scripts on Haiku, but I found that Vim for Haiku is not compiled with python, which seems to be a requirement for the GDScript autocompletion, … fixing means that too??
I might have said something wrong though. Just starting with Vim.
. But we must put extreme care here I guess. Vim is installed in almost every Haiku installation all around the world. Repackage it will break apart the systems were the users have customized the content of the versioned runtime dir I guess.
