3 ms·

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

by 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

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`.