4 ms·

> As much as I criticize Maven, I'm not sure what this process buys you over maven except... well... what DOES it buy you over Maven dependency management? I a

> As much as I criticize Maven, I'm not sure what this process buys you over maven except... well... what DOES it buy you over Maven dependency management? I agree that using Nix doesn't make sense for application development where all the dependencies are resolvable within the language runtime. (Provided the runtime itself can be well-specified in the project configuration and the language's dependency management system defaults to exact immutable declarations.) But throw in a dependency on Redis and Postgres, and you get into territory where traditional tools fall over pretty quickly, especially if different branches of your codebase depend upon different versions of Redis. Personally Guix is more interesting to me as a way to keep my own stuff declarative rather than for sharing across a team of developers. But the cost doesn't seem too high if your application has external dependencies which traditional tools suck at; I've felt that pain and it isn't pretty.

mercurial 11y ago
> But throw in a dependency on Redis and Postgres, and you get into territory where traditional tools fall over pretty quickly, especially if different branches of your codebase depend upon different versions of Redis. Surely you would just depend on the driver, which is most likely going to be written in your high-level language. A better point may be languages which rely a lot on C libraries (think Ruby and Python), and where having something like pip won't magically install the ImageMagick dependency your software needs.
- technomancy 11y ago
  The driver's not much good on its own. Traditional dependency systems force you to track the version of the server itself outside the project's configuration.
  - mercurial 11y ago
    So? This kind of service often sits on a different box anyway in production.
    - technomancy 11y ago
      I'm not sure what point you're making. Are you saying it's not important to run the same version of all your dependencies in development as in production?
      - mercurial 11y ago
        I'm saying that in production, your application will likely connect to a database on a remote machine, which may or not have the same version as the one you packaged and you use for local development.
  - KirinDave 11y ago
    It's very strange to imagine that you'd host a DB in a conceptually local manner to application services. This couples things in a way that's very awkward for scaling. Even if you're not using containers, you almost never organize deploys this way outside of beta/dev environments. And if you were to make such a decision, then you'd capture it in the closure required to run the code you built, so you'd sort of bake in the inclusion of those services into any deploy of your code, using Nix's philosophy. Or am I misunderstanding you?
    - technomancy 11y ago
      What I'm saying is that you should have a nix package for your application and one for your database server. Whether these run on the same machine or not is a question for how they're deployed, but it should be the same package that's pulled in by the production recipe and the dev recipe in any case.

mercurial 11y ago

> But throw in a dependency on Redis and Postgres, and you get into territory where traditional tools fall over pretty quickly, especially if different branches of your codebase depend upon different versions of Redis. Surely you would just depend on the driver, which is most likely going to be written in your high-level language. A better point may be languages which rely a lot on C libraries (think Ruby and Python), and where having something like pip won't magically install the ImageMagick dependency your software needs.

technomancy 11y ago
The driver's not much good on its own. Traditional dependency systems force you to track the version of the server itself outside the project's configuration.
- mercurial 11y ago
  So? This kind of service often sits on a different box anyway in production.
  - technomancy 11y ago
    I'm not sure what point you're making. Are you saying it's not important to run the same version of all your dependencies in development as in production?
    - mercurial 11y ago
      I'm saying that in production, your application will likely connect to a database on a remote machine, which may or not have the same version as the one you packaged and you use for local development.
- KirinDave 11y ago
  It's very strange to imagine that you'd host a DB in a conceptually local manner to application services. This couples things in a way that's very awkward for scaling. Even if you're not using containers, you almost never organize deploys this way outside of beta/dev environments. And if you were to make such a decision, then you'd capture it in the closure required to run the code you built, so you'd sort of bake in the inclusion of those services into any deploy of your code, using Nix's philosophy. Or am I misunderstanding you?
  - technomancy 11y ago
    What I'm saying is that you should have a nix package for your application and one for your database server. Whether these run on the same machine or not is a question for how they're deployed, but it should be the same package that's pulled in by the production recipe and the dev recipe in any case.