In reply to @522_:catgirl.cloud

... what's with this

# nix-instantiate --parse -E "01.4"
{
  "_type": "ExprCall",
  "args": [
    {
      "_type": "ExprLiteral",
      "value": 0.4,
      "valueType": "Float"
    }
  ],
  "fun": {
    "_type": "ExprLiteral",
    "value": 1,
    "valueType": "Int"
  }
}

... why is that not just a float literal with value 1.4

another input: i believe we kinda have to offer a default solution with a sensible UX at some point, but we're still in the phase of extracting flakes, etc. to make a sense of the ecosystem, unify/simplify/improve then we can elect a default solution that people can settle on

and maybe a hot take but i think at that moment, it would be good if all npins/lon/niv/etc. projects could be subsumed by This New Thing™ except if it's proven that having multiple solutions is required (because flexibility, etc.), this won't prevent people from having customized tailor-made solutions via the plugin system, but this shouldn't be the default scenario

I sometimes think about doing the New Thing, but I often stumbled into doing weird hacks or gross glue or re-implementations from scratch:

1. A good New Thing might want to do flake-import, but flake inputs are a very restricted subset of NixLang, being able to get them as JSON would be super helpful
2. Likewise, parsing flakerefs is not something exciting, and being able to turn flakerefs into JSON would be super helpful (flakes already understand both)
3. Getting NAR hash, store path, etc. from an arbitrary file/dir often feels unnecessarily complicated, so instead of simple git clone and getting hash, there's often a need to shell out to nix-prefetch-helpers

In reply to @kfears:matrix.org
But from my limited time, I felt the lack of plumbing commands badly

In reply to @k900:0upti.me
I feel like we need scoped pure eval first