jdxcode

8 ms·

1.
by jdxcode 3d ago
Yes I have a friend that can access my GitHub if I were to die and he would be in charge of deciding who would lead the project
2.
by jdxcode 3d ago
no, in fact you don’t even need node or npm to install npm packages with mise. (You likely will need it to execute them though)
3.
by jdxcode 3d ago
this makes no sense to me, the reason i don't give anyone else the commit bit is only to _protect_ the supply chain. you should want as few people with that access as possible.
4.
by jdxcode 7d ago
i thought the same thing but i bought a model y a few months ago and turns out that's exactly what I want. 90% self driving and really the 10% is entirely the last part of a drive because it picks stupid parking spots and doesn't
5.
by jdxcode 10d ago
for skills related to specific cli tools, i just wrote a standard for this! it's obviously not widely used yet, but since mise will support installing the skills alongside the tool, i suspect it will have decent adoption i used to be a
6.
Usage-rs: rust CLI framework from mise author that's 2500x faster than clap(github.com)
3 points by jdxcode 24d ago|0 comments
7.
by jdxcode 1mo ago
I'm biased but I think it's silly to think either one is going away anytime soon
8.
by jdxcode 1mo ago
well mise uses dotenvy right now (for env._file anyhow), it may be worth switching to dotenv-ng but I haven't looked into it yet https://github.com/jdx/mise/blob/fc441787fe52b46be1245046758... I assume y
9.
by jdxcode 1mo ago
90% of australians live in 0.22% of the country's land
10.
by jdxcode 2mo ago
i think that sentence is taken out of context a bit, the problem with those pkg binaries is that they're not portable—which the post describes EDIT: actually no, I think charlie is wrong on that point, he said the installers compile py
11.
by jdxcode 2mo ago
mise uses these as well and adopting them has been a massive improvement in the user experience for my python users. y'all have been doing a fantastic job maintaining them. i'm also doing the same for ruby—maintaining the binaries
12.
by jdxcode 3mo ago
I think node already does this (sans AI), idk where the code lives but deno could probably just use the same list of repos
13.
by jdxcode 3mo ago
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.
14.
by jdxcode 3mo ago
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
15.
by jdxcode 3mo ago
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 th
16.
by jdxcode 3mo ago
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 al
17.
by jdxcode 3mo ago
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
18.
by jdxcode 3mo ago
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
19.
by jdxcode 3mo ago
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
20.
by jdxcode 3mo ago
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.
21.
by jdxcode 3mo ago
how nix-pilled do you have to be to think that nix is the "only real solution" to dotfile managers?
22.
by jdxcode 3mo ago
Haven't looked into it but agents are so good at this I bet it'll be trivial to add
23.
by jdxcode 3mo ago
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 LaunchAge
24.
by jdxcode 3mo ago
mise isn't, and has the advantage that you don't need to build your own lightsaber with direnv and nix.
25.
by jdxcode 3mo ago
doesn't aqua:docker/compose just work? it does for me
26.
by jdxcode 3mo ago
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
27.
by jdxcode 4mo ago
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
28.
by jdxcode 4mo ago
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 an
29.
by jdxcode 4mo ago
Feeling is mutual!
30.
by jdxcode 4mo ago
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-y

More ›