Hacker News new | past | comments | ask | show | jobs | submit login
[flagged] Tea: A new package manager from the creator of brew (github.com/teaxyz)
211 points by thenipper on Nov 20, 2022 | hide | past | favorite | 130 comments



> Upon successful submission of a package, the package maintainer will receive an NFT to evidence their work and contribution. The holder of this NFT will automatically receive all rewards associated with the package. Package maintainers may transfer maintenance ownership over a package to another package maintainer by simply transferring the package’s NFT. Successful transfer of the NFT will lead to the new owner automatically receiving future package rewards.

I want literally nothing to do with a cross between a binary distribution tool and a cryptocurrency pump and dump.


It doesnt seem we're far away from any mention of "cypto" being a reason to flag (/ report spam).

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.


Many tech companies are both unprofitable and contribute near 0 value to society. Not unique to crypto. Be careful what you wish for, or the only people left paying software engineers might be non technical companies who pay $80k a year.


Programmers provide high economic multipliers on business activity and are typically in a good position to extract a proportionate reward for doing so.

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


I'd definitely prefer this outcome but I have a feeling we're going to go right back to where we were before as soon as interest rates come back down. Big tech starts aggressively overstaffing again while VCs pour money into mostly useless garbage. I've been doing this for awhile now, mostly in the startup space, and I'm not even sure if VCs care if there's even a viable business there. It often feels like a legal way of running what effectively amounts to a ponzi.


sure, SPAC IPO = dump part of pump & dump

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'


How do you define "unproductive businesses"?


$80k a year is totally reasonable comp for something one can learn in 1-2 years and pretty much master in another 5.


Given home prices are what they are now, I don't really think it's reasonable for mid or Sr level engineers making less money than what's required to afford a mortgage


What about people who cannot code, can they afford mortgage at all?


Probably less than half in the United States now sadly


Love to irreversibly lose control of my packages because of a phishing scam or a buggy smart contract!


LMAO the supply chain attack potential is epic. Oopsie the author of leftpad clicked the wrong button and now an unknown entity owns their package and just updated it with malicious content!


How is this different from our current signing key system?


My signing keys aren't tied to obscure 'smart contracts' that execute code when I do things like try to delete them.


If you are pwned you can contact pypi and get it fixed


Regular phishing. Oopsie!


No such a thing as a buggy smart contract. The contract is right by definition, and that is what was agreed upon. Therefore, it’s the humans who signed it who are buggy. Or something.

I wish I was joking.


I'm a bit confused. What you said is factually correct, but you're coming off as though you disagree with it.

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.


> I'm a bit confused. What you said is factually correct, but you're coming off as though you disagree with it.

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.


How does creating this NFT cause it to have value, and therefore reward the package maintainer? If the issue is that no one is putting money into the system, the solution can't be a more complicated way of ensuring that the non-existent money goes to the right person.


Isn't the email proof of ownership. Why do they need an NFT? The owner can change the email to another one when no longer wants to manage.

NFT seeems an overkill and author drank too much crypto-aid.


Not everyone runs their own mail servers.

This is no different from requiring proof of identity using an SSH key like you do with GitHub.


What makes you think this is a pump and dump scheme? Other than the word blockchain


The website linked, and it's associated information all absolutely scream red flags and is functionally similar to a hoard of other schemes. It's a technically simple product (distribute binaries from a webserver) with a completely arbitrary cryptocurrency stuffed onto the side, allowing for bombastic, buzzword filled claims which just defy reality. It attempts to promote itself by driving users who will get some form of profit sharing as part of their participation, promising some sort of rewards paid by the creator.

> 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.


Is the fact that many maintainers burn out and earn no money and little recognition not a serious problem?


That isn't a fact.

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.


> 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 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 see that as mainly a social problem, not a technical one.

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


This will pay them in quatloos, not money.


Many people will get some satisfaction out of it, if they only receive points or badges. Look at Stackoverflow or GH stars.


Those people are already getting paid in GitHub stars. Adding United Fruit Company dollars to the mix doesn’t make the compensation any more real.

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?


Yeah those GitHub stars really help with burnout. When you're wading through a hundred pointless PRs of people trying to pad their contribution stats, those GitHub stars just release all the tension.


yes indeed, which is why it deserves a serious solution and not this.


I think a bias against crypto is clouding your argument. Reading the whitepaper makes me wish Bitcoin had never existed, given I imagine plenty of people would apploud many of the ideas in it.

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.


The word NFT


I don't doubt that the author if tea is well-meaning, I think the issue is how it's going to get used, which is what the other poster was referring to.


Being associated with Binance.


I was excited until this crypto NFT bullshit. Smh.


Where is this mentioned? I was getting all excited reading the README file of tea until I saw this comment. Thank you!


Quote is directly from https://tea.xyz/tea.white-paper.pdf


On top of which I want literally nothing to do with Max Howell. He's the consummate brogrammer douche. 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.

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...


> Everyone uses brew because they have to, not because they want to.

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.


Why do you have to use brew - there are other package managers for macOS new ones like nixpkgs and ones much older than brew like Macports and Fink. All of these follow normal Unix standards e.g. like work on a multi user system.


Because Homebrew is unfortunately "the standard" and the first place a project will package for if availability for macOS is desired. As a Linux user, it's the worst package manager I've ever experienced but it is what everyone is using in my company who uses macOS (most people).


MacPorts is actively supported, with broad package support — and of course, pull requests for new packages are welcome.

v2.8 was just released on October 20th; changelog here: https://github.com/macports/macports-base/blob/v2.8.0/Change...


"pull requests for new packages are welcome" is the self-defeating answer: if you as a user have to create a PR for a package to be in MacPorts then it means that MacPorts have not attracted enough attention from the authors of the package to submit it themselves.


Very few package authors create packages in any packaging system. The ports are usually done by someone else often part of the package team.

e.g. who crates emacs or vim packages for debian nix etc?


In the Nix world, at least, packages are often added by people who want to use them. I think that's more common than the fulfillment of a packaging request.


It would be funny if the state of packaging on Linux would not be so pathetic.

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).


What are your complaints?


It's so slow: on the order of single digit minutes to a dozen to install a single package. It feels messy, like it's shotgunning my entire system with bits of itself (I don't know how true the reality of this is). I've not infrequently had packages simply fail to finally resolve after they did their dance of resolution. It does not inspire delight. The vibe, if you'll excuse me, is very crude cudgel.

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.


You don't absolutely have to use brew, but there's a sort of relentless soft pressure to use it because it's more or less the de facto standard package manager for macOS and has such a large collection of packages.

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.


> it's more or less the de facto standard package manager for macOS and has such a large collection of packages

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.


The thing that always makes me cave and install brew is I want to try some tool and its default install assumes brew.

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.


> [Max Howell] 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.

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.


This feels like an uncalled for ad-hominem attack. Also, I might be in the minority, but I actually _like_ brew?


I also like brew. The whole UX pipeline is smooth, and I don't mind if it takes an extra 30 seconds to install packages (which doesn't happen often).

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.


To be fair this is kind of a cool idea which is to allow open source package maintainers to earn based on popularity, the incentives here seem interesting at least.

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


Didn't find any reference in the readme, but was almost sure it's crypto-related the moment I saw the header image; the silly design style is so endemic that it simply shouts crypto on the visitor's face.


https://www.binance.com/en/blog/ecosystem/binance-labs-leads...

> Packages will be released on‐chain as NFTs with their dependency metadata included.

:thinking_emoji:


Oh god, WTF. I was half excited about this for a second but it's just crypto BS.


Same :(


Assuming Binance will put this on their BNB chain, yikes.

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.


> ^^ same one-liner but works for anyone on the Internet

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!


previously: https://news.ycombinator.com/item?id=30778924

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?


Yeah, wow.

“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.


"tea is creating new technologies that will change how open source is funded"

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.


I was very excited about this until I read the comments here. I didn’t notice the NFT/blockchain stuff when I read through the README, but I agree with other commenters here that that is very off-putting. I really don’t want anything to do with Web3 or anything blockchain.

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.


Maybe a person who can build a "saner Nix" might be smart enough to decide that "web3" is a good fit for the project?


"looks like" does not mean "is"- especially when the person commenting "looks like" didn't actually use it. It's pretty easy to build something that only "looks like" a saner nix.


Whether someone is technically talented and whether they have good judgment about "web3" have proved over the past few years to be entirely unrelated to each other.


Or maybe the person who decides "web3" is a good fit for the project isn't smart enough to build a "saner Nix".


Okay I read the full readme and things have changed since last time I read about this. Now this seems to bring actual neat features to package management vs. what exists now. I wonder how they did truly relocatable packages… probably like Nix did it, I suppose? If this really turns out to be an easier-than-Nix Nix, it could be great!

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.


TBH, I don't get excited about new package managers.

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.


I don't get angry for reinventing the wheel - but if you do, please make it compatible with state of the art existing tools. They at least seemed to have a try at that


Mandatory xkcd: https://xkcd.com/927/

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?


Very cool looking! This really speaks to me--no curating some global environment of tools, everything is per project. All of your dependencies defined in the README.md. I'm looking forward to playing with this!


Yes, finally package management like it was meant to be.

Hopefully it's less clunky than brew.


I've said it in previous threads about tea, but just to reiterate: Homebrew is not affiliated with tea, and its creator has not been involved in Homebrew for a long time (at least as long as I've helped maintain it, which is 6+ years at this point).


But the title is accurate no?


Yes. I meant that more as "Homebrew has undergone significant development changes since the creator of tea was last involved." In particular, the transition to the current architecture (favoring bottles over source builds on clients) happened well after him.

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.


Homebrew's kind of a dumpster fire now tho. The whole "you don't ever get to use an old version" thing was when I jumped ship. The fact that it can't handle two architectures in one install is also a big problem, though can be generally worked around


Homebrew is almost entirely beholden to the behavior of an operating system (and entire hardware ecosystem) that we have no say over. It also was simply never meant to be a versioned package manager, because the majority of its users (developers) want rolling updates for their tooling.

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.


I, for one, appreciate Homebrew. It’s the first thing I install on a fresh OS. Thanks for keeping it alive.


Same! I've heard quite some complaining about it, but I for one am still blissfully unaware of its supposed shortcomings after about 2 years of use.


Let me start by saying Homebrew is incredibly valuable and useful.

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 think I've answered the part about why we do bleeding edge updates below, but for the auto-updating and upgrading behavior: you can set `HOMEBREW_NO_AUTO_UPDATE=1` and `HOMEBREW_NO_INSTALL_UPGRADE=1` in your shell environment. The former will prevent silent updates of the taps, and the latter will prevent unrequested upgrades of outdated formulae (per tap state).


Making those behaviors the default would better serve the Principal of Least Surprise.


Homebrew is just git under the hood, so upgrading an arbitrarily old core and tap state to the latest release may not result in a correct migration. That’s arguably more surprising, since a user then has to contend with broken package state instead of the occasional inconvenience of an auto-upgrade.


My issue is installing a package. Brew has a local state of the universe. It could just install the new package I ask for. Instead it installs the package plus updates for other packages I have installed. More than once I've had those unrequested updates break. Then I'm stuck yak shaving trying to fix some random package because I dared to install a new one.

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.


>the majority of its users (developers) want rolling updates for their tooling.

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.


A huge amount of Linux users use rolling release distributions now (Arch, Manjaro, EndeavourOS, etc). I prefer it as well because I find it less disruptive than occasional big-bang versioned releases.

Where versioning matters, we have better tools than OS package managers now (ex Docker).


I'd much prefer a compromise, like the FreeBSD quarterly updates vs daily, so you can pick the update frequency.

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.


I am also in the camp of engineers who prefer stability over bleeding edge. But I do understand folks who prefer the latter modality. If dependencies are gonna break, often its more desirable to have them break quickly with a short remedial cadence to follow. In my own anecdotal experience though, "short" is probably too charitable of a descriptor for the time to fix.


For tools that I develop on I use asdf for versioning. For everything else I want the latest stable version, so homebrew works well.

On Linux I use a rolling release distro for the same effect.


I want rolling updates for my tooling.


[flagged]


>You should get out more. No offense.

This is an unnecessary comment.

>Incremental pain, delivered early, is both corrective and less expensive over the long run. If you need to remain version-locked for a specific reason, that reason is likely to be locally scoped rather than global, in which case TFA describes an attempt to address your problem.

This rests on the assumption of a relatively homogenized software development industry without any consideration for, at least, critical systems building. There's a broad range of disciplines in this industry which do not -- and cannot -- adhere to the practices you mention.


At my company, Homebrew is the de facto package manager for Mac. My team doesn't prefer constant rolling updates, but we do work around them. Have you polled users in any way to be sure that 99% of them consider this a feature, and not an issue they have to deal with?


It's based on our historical experience maintaining versions (or, at minimum, trying to not change the core DSL such that older formulae continue to work): we get an order of magnitude more requests for updates than requests for older versions, and even fewer specific complaints about breakage.

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!


Rolling updates are the #1 source of "I don't understand why this isn't working anymore, it worked just fine yesterday!" and annoyances when you need a specific package version (n-2) to align with your deployment environment and Homebrew keeps updating to the bleeding edge.

(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.)


I've used Homebrew for years.

WFM. YMMV.

Thanks so much!


Homebrew distrbutes recipes and bottles for older versions of many packages: postgres and node come to mind. And it's easy to maintain your own recipe if you need a different one.

https://stackoverflow.com/questions/3987683/homebrew-install...


It's a rolling-release package manager, that's what you get. It's the same with Macports and Pkgsrc.


This is like nix but in alpha and with NTFs. I'll stick to nix.


I like the part where tea is a virtual environment with freedom and everything.

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.


This is pretty interesting as the first general-purpose package manager outside of the functional package management paradigm to directly complete with Nix in terms of features like ephemeral shell environments and magic shebangs.

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.


Just when I though NFTs couldn’t get any dumber. The package manager itself seems interesting but I’m not touching it if it has crypto nonsense in it.


The security concerns here are really, really glaring. All the way down to having your system hacked, by someone who pushed crap to a blockchain, for merely sending a typo into your shell should you decide to install this piece of condensed insanity and the suggested shell hack. Null terminated strings and "billion dollar mistakes" are much saner than this.


This readme file reads like an infomercial / sales pitch. Further increasing my scepticism.


People here seem to really hate the blockchaininess of tea.

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


The other day I was looking for a simple, lightweight userspace binary package manager. Nix was exciting for a minute until I realized it requires root to install unless you jump through hoops.

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?


Nix does need root by default, but I use this https://github.com/nix-community/nix-user-chroot on all the Linux boxes I use.


Have you tried Homebrew?


I gave it a shot. It was way to slow for my use case. And I think it was several hundred MBs just for homebrew itself if I recall correctly.

Maybe software these days just has too many recursive dependencies.


I can see the benefit of installing things in the home directory. Thats something that was always frustrating with brew. You install postgres, but where do things like the configs and data directory live? But I also don’t want a bloated 50gb home dir.


FWIW, nix (the package manager) can do this right now, and without all the crypto BS attached.

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...


I really want to use and like Nix. But I don’t want to write code (in an esoteric programming language no one else uses, no less) to install/manage my dependencies! It feels too much like it’s trying to be an all-encompassing digital lifestyle instead of just a package manager that I think about only when I need to install a package.


Learning the syntax is the easy part, the language is quite simple with few rules. But, I agree with the other sentiments. It needs a better UX for it to be mainstream. There are few attempts being made[1][2], only time will tell

1: https://www.jetpack.io/devbox/docs/ 2: https://devenv.sh/


I am personally fed up with the brew devs and have switched to nix on my mac instead. The UX of brew is already disgusting, and I don't think a crypto-embedded package manager will be any better.


Use home manager instead.


I'm guessing the people publishing the package need to pay gas fees?

Not ideal since people make packages as a labor of love. Maybe a community fund to pay gas fees would work.


Not even just gas fees -- the publishers have to outright pay to get a package added:

> 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....


It's not ethereum, it's some other bespoke blockchain to issue NFTs on.


Honestly, the first paragraph cannot be serious and, if it is, I am sorry to say it is delusional (I am judging the text, not the person).


Considering the broken most basic basic fundamentals of packaing and system integration in brew since day one (installing shared executables and /usr/local itself as owned by a rando user steve or whoever happens to install brew) only partly fixed grudgingly and by force after Apple just took over ownership of the /usr and /usr/local directories, this fits. Another equally well considered idea.


Built with Deno


no native windows support:

> We already work on Linux, macOS, and WSL; soon we’ll support Windows natively.


In defense of Tea here, a proper package manager (as opposed to something that just downloads prebuilt binaries or installers directly from vendors) that runs natively on Windows is nonexistent and (I think) unprecedented (outside of POSIX emulation environments like MSYS2 and Cygwin).

(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.


This could've been human-friendly nix.

And then they went ahead and bolted NFTs onto it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: