jdxcode

I think node already does this (sans AI), idk where the code lives but deno could probably just use the same list of repos

I agree that it sucks not being able to have comments in package.json, but I think it's the right call to not adopt something like jsonc. It would break so much tooling at this point I don't think it would be worth it.

Your proposal wouldn't help me at all. I wouldn't say that the problem I'm having is even "spam" per se. (For context I receive hundreds of PRs each week across my OSS projects like mise)

In my case I sometimes get a flurry of PRs from over-exuberant contributors, not necessarily low quality even! Using this I can at least put some back-pressure on that and help keep things more fair across my contributors.

Considering nothing in that reply criticized nix you’re certainly wrong. I don’t hesitate to share my opinions on nix anytime (just like nix users themselves) so I’d have no reason to be coy about my criticism.

tfrancisl was polite (even though I arguably wasn’t in the beginning) so I felt it important to return the favor.

ALL mise features are experimental until the design is finalized. I don’t do breaking changes except in exceptional circumstances with a long procedure, so experimental means I have the liberty of making them in any release. It is not at all any marker of quality. That said, in practice I don’t make them often.

I’d argue it’s a good time to play with features since if you have any ideas on how it might better fit your workflow I still have the ability to change the design before it’s largely frozen.

I always like to mention rcm. It's not a popular one but I tried probably 10 managers before it and much prefer it to the competition: https://github.com/thoughtbot/rcm

I am genuinely confused. Are you saying dotfile managers need to be more complex? Or that nix's problem space is the only solution for the things in nix's domain? (of which dotfiles are just one—via home manager)

I thought it was the former but "just pulling a precompiled, dynamically linked binary and hoping it works" makes me think we're not on the same page since to me that has nothing to do with dotfiles.

it's dependency free. You don't even need brew to install brew formulas.

The "exception" to that are linux package managers like apt-get and dnf which it calls under the hood. I think can't be an actual issue since it's not like you would ever use ubuntu/redhat without their system package manager installed.

The problem with mise managing its own version is perf. I don't want a shim that has to read config files to exec the right version.

I would make use of min_version. It's not perfect, but will at least help bring laggards along.

how nix-pilled do you have to be to think that nix is the "only real solution" to dotfile managers?

Haven't looked into it but agents are so good at this I bet it'll be trivial to add

It’s quite new but I’ve been cooking up some new bootstrapping features with mise which people may find relevant here: https://mise.jdx.dev/bootstrap.html

It’s for things like dotfiles, apt/brew packages, and LaunchAgents/systemd.

EDIT: I feel a little bad having hijacked this, as someone that hears a lot of opinions about devtools I can definitely say chezmoi is a darling of the community and I highly recommend checking it out.

mise isn't, and has the advantage that you don't need to build your own lightsaber with direnv and nix.

doesn't aqua:docker/compose just work? it does for me

mise kind of supports dependencies, just not in the way people expect coming from any other package manager. The dependencies in mise are not automatic and all of them need to be manually defined. They're to get around ordering issues since mise installs in parallel, e.g.: if you use "pipx:black" you need to wait for python to finish installing. (This is the "depends" option on tools")

This is intentional as mise is not intended to be a full bootstrapping solution in the way homebrew/nix is, mise is designed to be an overlay on top of existing systems. So if you want to manage python with brew and black with mise it basically just works without extra configuration. I think this design decision has paid off in spades. It sounds like a drawback but at the end of the day it's probably the #1 reason users find mise easy to use.

1. the supply chain attacks I've seen are naive. They just leverage postinstall hooks. Malicious code also needs to be executed, not simply installed, so it's a lot less likely that an exploit would happen compared to postinstall since it can't just be buried in a transitive.

2. aube does the same. This is an extra level of protection if you've already whitelisted a package

In aube you get all this out of the box plus a lifecycle jail (next MV will have that on by default) and defaults to trustPolicy=no-downgrade (would not have helped here but still a good default).

It has the strongest security posture of any node pm.

https://aube.en.dev/security.html#jailed-lifecycle-scripts

Feeling is mutual!

it was definitely a risky move, env vars are not perfect for this use-case (varargs is awkward) but I'm happy I went with the file tasks setup and the magic comments anyways. It's nice that you're not working in bash-inside-yaml or coming up with a new file type. It is just bash.

I'm glad you're seeing it this way and finding value in it, this was very intentional. I wasn't happy with the status quo with all of the other tools in this space (nix, bazel, buck2, etc) that all force you to adopt everything from day 1. I think of mise as an overlay on existing systems, not a system in itself.

$600 was when I was working in a big tech job and while I had a sponsor page I didn't promote it whatsoever. I was surprised people were even willing to give that much given it was obvious I was making good money at my day job.

Now that this is a full time gig for me this has more than quadrupled—this post is a couple of weeks old. Also because I'm offering perks for the first time for people that pitch in. Still not enough to really make a living, but like I said in the post I have a few avenues I am trying out for revenue. I just hope that I can find something that maximizes the time I spend on the OSS tools while being sustainable.

this is probably the better link to what they were asking about: https://mise.jdx.dev/tasks/running-tasks.html#running-on-fil...

mise's sources/outputs is intentionally pretty naive though. It's not bazel/buck2. That may change one day but so far it's more for writing tasks and less trying to be an authoritative build system.

this is the leaderboard that matters for CLIs: https://formulae.brew.sh/analytics/install-on-request/30d/

it's 12th now. It was 10th when I wrote this post. GP is just mentioning what I wrote in the blog body.

I am the maintainer of fnox. This is only true if you use the encryption providers. If you don't, nothing is encrypted obviously.

Your doc also doesn't seem to take into account my preferred way of using it with KMS that solves a lot of the problems mentioned.

I've always wondered what "us-east-1" is, presumably it's more than just 1 building

yep!

lol with mise I used a fourth time unit: https://mise.jdx.dev/configuration/settings.html#install_bef...

wasn't it 1989 technically?

ok but I was replying to a comment about a tool which advertises precisely that feature

It's idiomatic in pre-commit to leverage the public plugins which all do their own tool installation. If you're not using them, and also not using it for tool installation, I'm not sure why you'd not be using the much simpler lefthook.

If you look at hk you will understand what I'm talking about in regards to parallelism. hk uses read/write locks and other techniques like processing --diff output to safely run multiple fixers in parallel without them stomping on each other. treefmt doesn't support this either, it won't let you run multiple fixers on the same file at the same time like hk will.

If the linters you're running are open source, isn't this what you're ultimately doing anyway?

You have to trust the linters. You don't also need to trust the plugin authors. In hk we don't really use "plugins" but the equivalent is first-party so you're not extending trust to extra parties beyond me and the lint vendors.