3 ms·

I was reading this thread and now I finally understood what you mean by plugins. Plugins kind of exist in Nix, except they're not called that. They are function

by elbear 3y ago

I was reading this thread and now I finally understood what you mean by plugins. Plugins kind of exist in Nix, except they're not called that. They are functions available in some specific module. For example, `dockerTools` provides different functions like creating an image and other things. There is a module of fetchers, functions that retrieve source files from GitHub and other sources. But I don't think there are many language-specific functions, like the ones you are describing. I can't think of any, except for the ones that build a Nix package from a language-specific package.

mkleczek 3y ago
There are attempts like https://flake.parts/ https://flake.parts/ or https://github.com/nix-community/flakelight https://github.com/nix-community/flakelight Their aim is to create an ecosystem of reusable Nix libraries. But it is tiny.
- elbear 3y ago
  Yes, I know about flake.parts (didn't know about the other one). But I'm not aware of the kind of libraries you mentioned. There's FlakeHub[0], which is like a package index for flakes, so maybe we'll start to see there reusable stuff. [0]: https://flakehub.com/flakes https://flakehub.com/flakes
  - mkleczek 3y ago
    To be honest, now when I'm thinking about it - it seems to me Nix main weakness here is that it is a separate language and runtime. Writing a Maven plugin (ie. a reusable piece of configuration management logic) is easy because you can use any library from the vast Java ecosystem (just add a library as a dependency of your plugin). Doing the same in Nix requires recreating these libraries in Nix. Looks like Maven might simply be the right choice...
    - elbear 3y ago
      You can have a hybrid approach, where you use Nix to provide the build environment (which includes Maven, for example). Then you use the Java-specific tools for the build itself. This should ensure your build has a high degree of reproducibility.
      - mkleczek 3y ago
        That won't cut it as I need a multi-language build. And don't get me wrong - I know it _can_ be done in Nix (as it is a programming language) - the question is _how easy_ it is to create/maintain it. Let's say my solution requires a Java Spring Boot application, React client, custom Postgres extension and Python ML code.
        elbear 3y ago
        Well, you can provide in your environment all the binaries needed: - Java stuff - node and npm - I don't know what you would need for Postgres extensions - Python, pip or poetry (or whatever you use for Python package management) Here is an example flake: https://bpa.st/ZUQQ https://bpa.st/ZUQQ Under `devShells`, you have `packages`. You can put there any package from nixpkgs, not just Python packages like I have there. To make it cleaner, you could have a variable for each platform and concatenate them under packages like `packages = javaPkgs ++ nodePkgs ++ pgPkgs ++ pyPkgs`.

by elbear 3y ago

mkleczek 3y ago

There are attempts like https://flake.parts/ https://flake.parts/ or https://github.com/nix-community/flakelight https://github.com/nix-community/flakelight Their aim is to create an ecosystem of reusable Nix libraries. But it is tiny.

elbear 3y ago
Yes, I know about flake.parts (didn't know about the other one). But I'm not aware of the kind of libraries you mentioned. There's FlakeHub[0], which is like a package index for flakes, so maybe we'll start to see there reusable stuff. [0]: https://flakehub.com/flakes https://flakehub.com/flakes
- mkleczek 3y ago
  To be honest, now when I'm thinking about it - it seems to me Nix main weakness here is that it is a separate language and runtime. Writing a Maven plugin (ie. a reusable piece of configuration management logic) is easy because you can use any library from the vast Java ecosystem (just add a library as a dependency of your plugin). Doing the same in Nix requires recreating these libraries in Nix. Looks like Maven might simply be the right choice...
  - elbear 3y ago
    You can have a hybrid approach, where you use Nix to provide the build environment (which includes Maven, for example). Then you use the Java-specific tools for the build itself. This should ensure your build has a high degree of reproducibility.
    - mkleczek 3y ago
      That won't cut it as I need a multi-language build. And don't get me wrong - I know it _can_ be done in Nix (as it is a programming language) - the question is _how easy_ it is to create/maintain it. Let's say my solution requires a Java Spring Boot application, React client, custom Postgres extension and Python ML code.
      - elbear 3y ago
        Well, you can provide in your environment all the binaries needed: - Java stuff - node and npm - I don't know what you would need for Postgres extensions - Python, pip or poetry (or whatever you use for Python package management) Here is an example flake: https://bpa.st/ZUQQ https://bpa.st/ZUQQ Under `devShells`, you have `packages`. You can put there any package from nixpkgs, not just Python packages like I have there. To make it cleaner, you could have a variable for each platform and concatenate them under packages like `packages = javaPkgs ++ nodePkgs ++ pgPkgs ++ pyPkgs`.