4 ms·

That looks completely inscrutable to me. Like a sequence of magic words. I don't see the connection with JSON at all.

vertex-four 7y ago
I'm not really sure what you're finding inscrutable. I'll tear out the boilerplate that explains that this file is a function and returns a Python application (which is documented in the nixpkgs manual and can just be copy-pasted if you really don't want to figure out what it does): rec { name = "quicktill"; src = ./.; doCheck = false; propagatedBuildInputs = with python3Packages; [ dateutil pyyaml sqlalchemy psycopg2 pycups reportlab requests_oauthlib pygobject3 ]; nativeBuildInputs = [ wrapGAppsHook ]; buildInputs = [ gobjectIntrospection gtk3 ]; } Is that any better? It looks an awful lot like some dialect of something JSON-like to me - there's some different symbols used and array values are separated with spaces rather than commas, but aside from that it's just a record of key-value pairs. From there, the first line in the original example says "the following expression is a function that is called with this parameter", and the parameter is an object containing a key called "pkgs", which is defaulted to the result of "import <nixpkgs> {}". This is explained in more detail in a handful of lines in the language manual. Functions are called just by referencing the function and then the arguments separated with spaces, like Ruby or Haskell - so python3Packages.buildPythonApplication is a function that is called with the object above. Finally, "with foo;" just means "every key in foo can be accessed without typing foo. in the next expression". The result is basically: this file defines a function which takes an object containing the package repository as the "pkgs" key, and returns the result of calling pkgs.python3Packages.buildPythonApplication with the object defined in the rest of the file. It's a lot more derived from the syntax of functional languages than C-like ones, but that's not necessarily a bad thing. Also: this is basically the entire language. There's a couple of different string syntaxes and some stuff for merging objects together, and also a mechanism for temporarily naming things that aren't part of an object, but in general... there's not a lot more to it. Most of the complexity is in the domain itself - what's the difference between a propagated, native and regular build input, how do you manage plugins and options for a package, etc. What's your preferred packaging DSL?
- jforberg 7y ago
  I mostly deal with openembedded at work and I have few positive things to say about it. I'm sure Nix is much faster and nicer. Frankly it's hard to imagine that the opposite could be true. But your example looks nothing like Json.
  - vertex-four 7y ago
    I'm not sure what to say. Replace the = signs with colons, the semicolons with commas, stick commas between array elements and stick everything between quotes and you basically have json.
    - tannhaeuser 7y ago
      That looks like a Turing-complete DSL. Not like JSON at all. Do we need yet another Turing-complete language for writing package metadata?
      - viraptor 7y ago
        The example lacks functions / flow-control statements (ok, apart from "import if not defined", but it's more of a default value than a branch) / references to other elements. It's pretty much key-value dictionary. Not sure how you got an impression of Turing-complete DSL from that, since it would require at least one of them.
        weberc2 7y ago
        The Nix expression language has branches and functions (including recursive functions). It is Turing complete, and it probably is necessary for its charter.
        viraptor 7y ago
        OP said it "looks like" a Turing complete DSL just from the example. Regardless of what extra functionality the actually is, the examples didn't suggest it.

I'm not really sure what you're finding inscrutable. I'll tear out the boilerplate that explains that this file is a function and returns a Python application (which is documented in the nixpkgs manual and can just be copy-pasted if you really don't want to figure out what it does): rec { name = "quicktill"; src = ./.; doCheck = false; propagatedBuildInputs = with python3Packages; [ dateutil pyyaml sqlalchemy psycopg2 pycups reportlab requests_oauthlib pygobject3 ]; nativeBuildInputs = [ wrapGAppsHook ]; buildInputs = [ gobjectIntrospection gtk3 ]; } Is that any better? It looks an awful lot like some dialect of something JSON-like to me - there's some different symbols used and array values are separated with spaces rather than commas, but aside from that it's just a record of key-value pairs. From there, the first line in the original example says "the following expression is a function that is called with this parameter", and the parameter is an object containing a key called "pkgs", which is defaulted to the result of "import <nixpkgs> {}". This is explained in more detail in a handful of lines in the language manual. Functions are called just by referencing the function and then the arguments separated with spaces, like Ruby or Haskell - so python3Packages.buildPythonApplication is a function that is called with the object above. Finally, "with foo;" just means "every key in foo can be accessed without typing foo. in the next expression". The result is basically: this file defines a function which takes an object containing the package repository as the "pkgs" key, and returns the result of calling pkgs.python3Packages.buildPythonApplication with the object defined in the rest of the file. It's a lot more derived from the syntax of functional languages than C-like ones, but that's not necessarily a bad thing. Also: this is basically the entire language. There's a couple of different string syntaxes and some stuff for merging objects together, and also a mechanism for temporarily naming things that aren't part of an object, but in general... there's not a lot more to it. Most of the complexity is in the domain itself - what's the difference between a propagated, native and regular build input, how do you manage plugins and options for a package, etc. What's your preferred packaging DSL?

jforberg 7y ago
I mostly deal with openembedded at work and I have few positive things to say about it. I'm sure Nix is much faster and nicer. Frankly it's hard to imagine that the opposite could be true. But your example looks nothing like Json.
- vertex-four 7y ago
  I'm not sure what to say. Replace the = signs with colons, the semicolons with commas, stick commas between array elements and stick everything between quotes and you basically have json.
  - tannhaeuser 7y ago
    That looks like a Turing-complete DSL. Not like JSON at all. Do we need yet another Turing-complete language for writing package metadata?
    - viraptor 7y ago
      The example lacks functions / flow-control statements (ok, apart from "import if not defined", but it's more of a default value than a branch) / references to other elements. It's pretty much key-value dictionary. Not sure how you got an impression of Turing-complete DSL from that, since it would require at least one of them.
      - weberc2 7y ago
        The Nix expression language has branches and functions (including recursive functions). It is Turing complete, and it probably is necessary for its charter.
        viraptor 7y ago
        OP said it "looks like" a Turing complete DSL just from the example. Regardless of what extra functionality the actually is, the examples didn't suggest it.