Modelling vcv-rack after vim or emacs etc

Help
1

There is already a package expression for vcv-rack but I would be interested in extending it by adding a package expression as vim or emacs do.
There are lots of awesome vcv-rack packages out there all using a similar build approach basically and I like the idea of using them in a nix fashion.
Where would I start rewriting a basic package to have something as plugins/packages on their own ?
Hope this last sentence does not sound too confusing.

Thx!

2

Do you mean that you’d like to install vcv-rack + plugins by expression such as vcv-rack.withPlugins (p: [ p.Fundamental p.AudibleInstruments p.Befaco ])? Haven’t looked into this very deeply but I think the general steps would be:

  1. Extend the vcv-rack derivation to create dev output in addition to the main output. The contents of the output need to resemble the vcv-rack SDK, i.e. headers and other files needed to build plugins.
  2. Write derivations for each plugin. These are going to be pretty similar so common steps can be factored out but probably won’t be entirely the same due to dependencies. They are going to have vcv-rack as an input so they can do RACK_SDK=${vcv-rack.dev} during the build.
  3. Put all the plugins in an attribute set.
  4. Write the withPlugins expression which takes one argument, a function from the abovementioned set to a list of choice of plugins. Something like roundcube has but instead of the buildEnv it needs to construct a wrapper that runs vcv-rack with the plugins. Maybe it can build a directory with symlinks to the chosen plugins and in the wrapper invoke Rack -s theDirectory?

Good luck, if unsure grep the nixpkgs repo a lot:)

1 Like
3

@b42, exactly what I meant assuming I don’t have much experience going into the details, maybe this isn’t a learners topic.
Can I do this ? IDK, once before daring try nix hacked together a docker-based approach, just a gist over at github, not very useable for anybody except me I guess. Will try definitely.
I would really like to join someone’s effort in your points direction in case there is anybody.

4

It seems doable and certainly a good way to learn more about Nix:) Perhaps get in touch with maintainers of the package and ask them if they like the idea?

Re 1. here’s similar change for LibreOffice. Re 2.&3. ZNC modules are a nice example. I think 4. might be the trickiest, e.g. not sure how immutable plugins dir is going to interact with the built-in plugin manager.