Tea unifies representation and declaration by using readme.md as authoritative source for metadata annotation (also: genious marketing)
I guess the battle is on and tea might go a long way by it’s choosing of yaml as the data language for it’s “registry” called pantry (not the same as a flakes registry; more like flake registry + flake / nixpkgs in one) — in addition to being brew2 by the same author.
For the Nix Ecosystem, I’d draw some preliminary conclusions (20min; few shots):
Package as data is a thing for interoperability (the best thing that could happen would be a tea adapater into nixpkgs and vice-versa)
A Markdown metadata schema + builtin parser (e.g. replicating somewhat flake semantics) might get us a long way to catch up on UX & the genious idea to encode data as representation
We might need to double our efforts to work together on something like PUrl to stay interoperable
Proper layering and internal boundaries of our stack to get out of the “snowflake” corner (honorable mention of the work of the Nixpkgs Architecture Team!!)
Transparent boilerplate is nice, but some people need “magic”, too
What are your forward looking thoughts on this (hipshot analysis)?
Use a fancy ponzi scheme (“NFT”) to manage maintainership
I don’t see a big difference to flake URIs. Also we don’t need to chase after any new things just because it is new and hyped.
That works if you can trust upstreams dependency management which for example you can’t in the case of python or you end up using 2 to 3 year old cryptographic libraries like cryptography left, right and center which is bad.
Managing dependencies ourselves in such a limited metadata format works great until you need to do anything a bit more fancy and need some programming language.
IMO we could put our current mkDerivation attrs into yaml and into such a header but why?
tea is not declarative which is nix biggest strength. Interpreter problem is already solved by nix-shell and tea pipelines is probably the biggest sin of the project. I cannot imagine how they are going to work reliable and fast. As soon as my internet has a hicup they either fall apart or could get trapped in some retry loop. Also they are the opposite of being reproducible and I don’t want to even start from a security perspective.
I find this sentiment quite sympathetic, but it hits the wrong category. The category I intended to reference isn’t “(degree of) conservatism”, the category I intended is “(degree of) interoperability”.
If there is an emerging standard to be spotted (PUrl or the like), the Nix ecosystem would be more useful as an active participant in shaping such standard than as a late follower.
Re: package-as-data and overrides
I think there is a misunderstanding in play: the data property is already inherent to a Nix derivation and just as any data it can be overlayed. After all, functions render data, overlays mutate it. I think mutation is a pretty solid primitive for what you describe, whereas functions are good for DRY in the codebase.
But this also means, there is not real penalty to applying the data principle to nixpkgs and I think the Nixpkgs Architecture Team is slowly moving in that direction.
(yaml is but one representation of data, nix is good at it as well)
Overall, this isn’t an attempt to pitch Nix against Tea. Hence, I don’t think there is a need to pitch Nix’ strength to this community.
I think this is a true learning opportunity for us and can help us to embrace several areas of development in which Tea is good at.
I particularily feel that it’s fusion with markdown is genious. Everyone writes a readme, and everyone writes some stuff about dependencies, building etc. If you write a flake, and then a readme, that’s already duplicated work. If you think about it, Markdown is really good enough to both hold and render metadata. Because of that second property, it also self-documents.
Maybe a little example could help get imagination going:
<!-- we could work with frontmatter -->
---
inputs:
nixpkgs: github:nixos/nixpkgs
outputs:
packages:
default: /* invent something simple & smart as happy path for the simple case */
---
<!-- we could work with regular markdown, as well -->
# Hello v3.4
<!-- ^^ becomes the derivation's pname & version -->
Hello is a simple demo program to greet.you in plain english.
<!-- ^^ becomes the derivation's (and flakes'?) description -->
# Metadata (Nix)
## Inputs
| --- | --- |
| nixpkgs | github:nixos/nixpkgs |
## Outputs
### Packages
| --- | --- |
| default | some UX magic here |
| hello | some UX magic here |
Question to think about: how would the UX magic for outputs as data or as part of a markdown table have to look like?
We could even think about Nix type frontmatter (as styx is already capable of doing):
---
# nix
{
inputs = {};
outputs = {...}: {};
}
---
# Hello v3.4
<!-- ^^ might still provide pname & version inputs -->
What’s the point, then? → the theme of bringing declaration and rendering closer together and hoist synergies in intelligent ways.
All that being said, escaping into a fully fledged flake.nix should be still easy and seamless.
I don’t understand what’s the purpose of tea? I only see it as yet another unstable and complex stack to add to the pile, to make things even more complicated
By type inferrence from the overall narrative, I would say: nix develop with better UX and a stronger marketing base (and posture).
So is it a NIH (not-invented-here) imitation of Nix? Technically: probably yes, but complementing with UX and marketing base, I’m not sure if we can still say that.
Overall, the question that may be relevant and beneficial to us: what can we learn from them?
And if it’s an NIH copy-cat, I guess we can but draw our lessons ourselves and become more interoperable (so that the next copy cat can and also will likely leverage nixpkgs).
I would just say that there would be no need/market for tea (or things like flox for that matter) if the UX of Nix was where it should (and hopefully will) be.
If they handle some part of that circuit better than we do, all the better for us to adapt, if not, then nothing lost. I just thought it was funny that the thing was written in typescript
I half expected to see Nix half way down the README (as a backend), but alas.
