Tea: A new package manager from the creator of brew
github.com
github.com
I want literally nothing to do with a cross between a binary distribution tool and a cryptocurrency pump and dump.
As the economic recession accelerates, one of its few joys will be the charlatans paying on super-easy-mode being exposed for the useless players they are.
I feel that the major cultish hype-cycle of the last decade is rolling back, and my stress levels are dropping.
If we kill off that group of people earning 300k+ in unproductive businesses, all the better. I'd prefer that money be invested in more productive tech, and i'd suppose would generally raise salaries -- since atm, ex hypoth., it is just being burnt
However, just as ponzi in fiance was culturally and legally pushed out --- i'd imagine it will now in tech.
I suspect regulation and cultural scepticism will arise which secures the next two or three decades against this, 'as a rule'
I wish I was joking.
The first thing I was ever taught in my formal CS education is that the computer is (nearly) always right -- if there's a bug it's the programmer's fault. How is that not the case with a smart contract? How is that not the case in the real-world when there are loopholes in laws and contracts? Obviously you can always ask the courts for remediation in the real-world, but let me please point you to many examples where courts make an incorrect/unreasonable decision.
It is factually correct, and I also have an issue with it, yes. “There can be no bug in a smart contract by definition” is at the same time true and ridiculous. My problem is using this as contracts, which are agreements between two faillible human beings. In reality, mistakes are everywhere and we have fairly robust ways of dealing with mistakes in contracts. In contrast, what would be a bug in any other situation becomes the truth, with no recourse. This is typical of 2 fallacies in some tech circles: every problem has a purely technological solution, and we don’t need those old fashioned real-world institutions.
Smart contracts are a very fancy hammer when we’d need a screwdriver.
OTOH, I don’t have anything against willing participants having fun with smart contracts.
NFT seeems an overkill and author drank too much crypto-aid.
This is no different from requiring proof of identity using an SSH key like you do with GitHub.
> Package maintainers will publish their releases to a decentralized registry powered by a Byzantine fault-tolerant blockchain to eliminate single sources of failure, provide immutable releases, and allow communities to govern their regions of the open-source ecosystem, independent of external agendas.
It's existence is an attempt to justify the creation of yet another cryptocurrency, not as a serious solution to any problem that exists in distributing software.
Keep in mind that this scheme wouldn't reward the authors of software -- it rewards the people who create and upload packages. Those usually aren't the same people, and the maintainers that are most subject to burnout are the authors, not the packagers.
It also appears to require those developers to purchase (or otherwise acquire) tokens before adding software to the packaging system.
It creates an incentive to package software for the ecosystem, which is a pretty good goal to achieve for a package manager -- especially a brand new one where it would be hard to gain traction without a large number of packages.
I've noticed that a lot of crypto enthusiasts tend to reach for technical solutions without understanding the social causes of the problem in the first place
What money will be entering this ecosystem? Absent funds flowing in, how will package maintainers be able to convert their tea bucks to something they can pay rent with?
With all the flaws of npm, people do want to be able to have a immutable, mirrorable package-repository with a trust framework they can independently confirm. This does that, along with clever extras like "tasters" who stake a certain amount of value before confirming a package does x.
It's.. sad, that any tech that uses blockchain is now doomed to flag-death because of everything. I get it, but can't help but wonder how I'd have felt reading this paper 10 years ago.
He should go to a few conferences, introduce himself under another name, and bring up brew. I'd guess after half a dozen encounters he'd stop incessantly bragging about being the creator of brew.
Everyone uses brew because they have to, not because they want to.
I'm torn between the brew team being full of insufferable people because they don't know this, and arrogant because they do know it...
What?
Homebrew is easily one of my favorite pieces of software. It's the first thing I install on any new macOS or Linux machine.
Almost every piece of software I want to install is easily installable via Homebrew. The versions it has is almost always more up-to-date than what's in apt or yum. On macOS I can install all of my GUI apps with Homebrew Cask.
I have my Brewfile with my dotfiles so that any time I get a new machine it's easy to install everything I need. Just this week I updated my dotfiles to install Homebrew + my common development utilities on GitHub Codespaces. Without Homebrew I'd have a long, long, long script downloading packages from source verifying keys, installing dependencies, and then finally installing some software.
Aside from that, there are alternatives to Homebrew. Install things yourself from source, or use MacPorts.
> Whined about getting asked to do a code exercise at a google interview, bragging about how he made a project in use by X percent of the company's engineers.
My guess is that you support the status quo of software engineering interviews. That's fine, but many don't.
v2.8 was just released on October 20th; changelog here: https://github.com/macports/macports-base/blob/v2.8.0/Change...
e.g. who crates emacs or vim packages for debian nix etc?
If authors care about Windows they do produce Windows installers and/or publish it in their store.
If authors care about macOS, they produce .dmg or publish the app via Mac Store. Additionally they often publish it on Homebrew.
If authors care about Linux, they provide packages for Ubuntu and Fedora, and sometimes for more distros from the long tail (usually Debian comes 3rd as it is simple to add after Ubuntu).
Oh, the install location it asks you about when installing Linuxbrew is extremely odd. One choice offered is to make a dedicated brew user directory and then install there? That's terrible practice. No one else does this because it's terrible. And then the other apparently breaks a bunch of stuff and is not recommended.
I rather dislike it, and I periodically purge it from my system. So far I've always ended up reluctantly adding it back because I was trying out some tool or other that was dramatically more of a pain to install without brew.
I can get by for a long time without it, but then I want to try out something that assumes brew, or whose dependencies assume brew, and it winds up back on my system again until I get vexed enough to remove it again.
I definitely see the social pressure. That said, I’ve never needed to use it because I needed a package that was not on Macports. So far for my use no difference in the number of packages in the default repositories has been meaningful.
Now, I'll bet in close to 100% of cases I could get things to work with stuff from MacPorts instead, but I've accumulated thirty years worth of scars that incline me to want to stick as closely as possible to the defaults when trying something new.
So I end up going back to brew, even though I don't much like it.
I share your opinion of the technical execution of Homebrew— probably anyone with a deep Linux background would. But I think Howell is well aware of those deficiencies by now (and many may even have been clear to him at the start).
I also think that it's worthwhile for us haters to take seriously what Homebrew gets right, and that means admitting that it's a tool that many, many people have experienced as pleasant and useful. The tidy subcommand interface, relative simplicity, choice of popular/trendy tools (Ruby, at the time of Homebrew's creation), inviting and consistent (if controversial) use of metaphor, and playful tone (small jokes on the docs, use of emoji in CLI output), are all things that have proven to make a real difference in Homebrew's success. None of those speak to package management fundamentals, but they're real strengths and they are visible to all users of Homebrew right away, whether they know much about package management or not.
I feel you about being basically forced to use Homebrew, though. That sucks. It's frustrating to feel hampered by the tools your team uses when you know there are better ones out there but you just can't reverse the team's inertia.
The brewfile (as someone mentioned) is super convenient, and the fact that I can use the same package manager for mac and linux is nontrivially awesome.
However I highly doubt the original intention behind the NFT collaboration was altruistic to begin with.
Meaning at this point I don’t really trust any altruism in crypto in general (“hey we’re not trying to scam you we really are trying to change the world”).
The idea itself though was interesting to me: getting paid on a token based system for maintaining your open source package
> Packages will be released on‐chain as NFTs with their dependency metadata included.
:thinking_emoji:
BNB is filled with more trash, spam, and scams than even other chains. Most people in the space don’t even want anything to do with it - which is really saying something.
Oh my God, a one-liner that pipes curl to sh, downloads and executes a package from npm, and spins up a web server serving whichever directory you were unlucky enough to be in, all without a single confirmation prompt or authenticity check. And it’s blockchain!
interesting that the page barely mentions the blockchain, which seemed to be the key selling point on the page at launch.
I guess nowadays you should use tea if you wish that nix had fewer packages and more blockchain?
“Authenticating your GitHub entitles you to unique NFT reward badges, including one with rare artwork specific to how soon you authenticate.”
Not touching this then.
They are trying new approaches to a persisting problem. Nothing wrong with trying out new things like this, whatever works.
Let's see the results and make judgments based on that.
It’s a bummer too, because it looks like a more sane version of using Nix as a package manager. I’ve written about this elsewhere, but my experience using Nix as a package manager on macOS was very bad. I understand the value proposition of isolated development environments, but the execution with Nix left a lot to be desired (in my experience). Something that provides similar benefits in a nicer package would be very welcome.
There’s still the NFT/crypto side I do not like, but the product looks somewhat fair compared to what this was a few months back.
The last thing I want is a balkanized distribution space, and every new package manager is just one more place that package maintainers have to be aware of, learn, and configure. That makes each one a net negative by default, so the value-add that other package managers don't bring to the table has to be significant to get my attention.
Same here, I don't need another package manager. There's no need to create another one. Why not re-use existing technology instead of re-inventing the wheel all the time?
Hopefully it's less clunky than brew.
Edit: One of the reasons why I think it's important to continue to clarify this is because tea's repository description contains "brew2," implying a successor relationship.
You want different things than Homebrew was designed to do, which is perfectly fine. But we make those constraints abundantly clear in our documentation, and they produce a vastly better user experience for 99% of our users.
That said, the insistence on everything updating all the time is very frustrating. Being stuck waiting 30 seconds when trying to install something because brew is updating despite no one asking it to, random things breaking after an update, and needing to find escape hatches so an older version of some package can be installed are all pretty painful.
Perhaps I too am in the minority here.
I really appreciate the work all the Homebrew developers do. But I've lost a lot of time chasing down problems caused just because I installed some stupid utility.
I haven't met a single software developer who wants this. That's not to say your statement is incorrect -- I have no evidence stating otherwise -- but the idea boggles my mind.
Where versioning matters, we have better tools than OS package managers now (ex Docker).
I can't tell you the total number of wasted hours my previous organisation spent upon maintaining MacOS infrastructure after random breakage due to homebrew, but it was a regular occurrence and likely a few hundreds of hours per year for the small setup we looked after, mainly for CI.
On Linux I use a rolling release distro for the same effect.
When a particular package (or version) is widely adopted and difficult to migrate away from (like versions of LLVM, Postgres, or Python), we provide `@`-discriminated versions to allow people to migrate at their own pace. If there's a particular formula you want versioned that we don't currently, please open an issue so that we can discuss it!
(Beggars can't be choosers, etc. — I recognize the utility that Homebrew has provided to millions of people, that doesn't mean I can't mention its problems.)
WFM. YMMV.
Thanks so much!
https://stackoverflow.com/questions/3987683/homebrew-install...
I do not like the part where "tea is creating new technologies that will change how open source is funded" with all those buzzwords, NFTs and stuff.
Those are totally different problems and I do not want a middle man who sits on both payments and distribution - this is a direct road to an utopian walled garden which it will inevitably become, sooner or later.
At a glance, it's not a reimplementation of Nix with a porcelain. It makes no attempt at Nix-like hermeticity; installation of tea itself fails on NixOS with a dynamic linking error. But it also has the strengths one would expect from the creator of Homebrew taking a second stab at general-purpose package management: the documentation and CLI are charming (if incomplete), it's much faster than Homebrew, and it adds capabilities that Homebrew lacks and which are rare outside of the Nix world.
As a Nix person, I'm definitely interested to see what tea can achieve and what kind of userbase it ends up attracting. The less strict approach, day-one emphasis on UX, and choice of a 'dumb', commonplace configuration DSL (YAML) for package definitions could certainly incline a lot of people who shy away from Nix to give it a try.
I wonder how binary caching and relocatability are solved, given the apparent per-user prefixes in the homedirs.
Nix is really blowing up right now, and still has a huge head start in the breadth and usefulness of Nixpkgs. But a competitor like this really vindicates the recent turn towards emphasizing UX and documentation. If Nix developers to get the new CLI and the flakes schema formally released soon, I think we'll be come out ahead even of 'next-gen' efforts from outside the paradigm, like tea. If they don't, it'll be a missed opportunity for our community.
We'll see how it pans out. Had anyone tried registering any packages?
I have a toy package on npm, maybe I'll run through the paces
My goal is to be able to have something so lightweight and fast I don't hesitate to use it to install my favorite packages on every ephemeral VM I spin up. Anything like this out there?
Maybe software these days just has too many recursive dependencies.
https://nixos.org/manual/nix/stable/quick-start.html
For example, here's the config to set up development environment for headscale:
https://github.com/juanfont/headscale/blob/6a311f4ab68a4d856...
1: https://www.jetpack.io/devbox/docs/ 2: https://devenv.sh/
Not ideal since people make packages as a labor of love. Maybe a community fund to pay gas fees would work.
> Specifically, the package maintainer must:
> [...] Contribute to the package’s reputation and trustworthiness by steeping tea tokens.
https://github.com/teaxyz/white-paper/blob/main/white-paper....
> We already work on Linux, macOS, and WSL; soon we’ll support Windows natively.
(The closest thing to a real package manager in terms of use cases (used for installing things like command line tools and compilers) on Windows is Scoop. But it doesn't use a repo built from a ports tree or a collection of source packages like apt, Homebrew, MacPorts, Nix, etc.)
Tea isn't neglecting a common platform in its problem domain, and by even planning native Windows support it's actually pretty exceptional.
And then they went ahead and bolted NFTs onto it.