jdxcode

do you happen to have any examples of what didn't work well? I'm just curious as I switched to vscode and later jetbrains after a decade with vim and I find all of them to be great, though I usually have to modify an option or 2 to get it how I like

what the heck is "four-dimensional drag-and-drop"?

I totally see the point of this, but still, you have to admit this is pretty funny:

> Developers sometimes experience trouble debugging the quarter-million line amalgamation source file because some debuggers are only able to handle source code line numbers less than 32,768 [...] To circumvent this limitation, the amalgamation is also available in a split form, consisting of files "sqlite3-1.c", "sqlite3-2.c", and so forth, where each file is less than 32,768 lines in length

homepod?

that's not how meson describes itself:

> Meson is an open source build system meant to be both extremely fast, and, even more importantly, as user friendly as possible.

now I've never used it, so I can't directly defend that claim. I have heard good things about meson though and it would seem strange to me such a headline would make sense on a project that I also hear good things about.

what about meson?

> If mise watch -t run -- -r is too hard to remember

in recent versions this can be simplified to `mise watch -r run`

I am very difficult to please when it comes to dotfile managers. I tried all of them and I'm quite fond of rcm[0]. It's been a few years so it's hard for me to remember exactly what it was but I think both chezmoi and yadm involved some kind of step to "apply" changes but I just want things symlinked into a dotfiles repo that I have a cron job which basically does `git ci -a && git push` to synchronize changes.

That said, I don't think rcm should be anyone's first choice. I'd check it out if nothing else seems to work for you. From what I hear, chezmoi seems to be most people's favorite so I'd start there. I don't know a single other person that uses rcm.

[0] https://thoughtbot.github.io/rcm/rcm.7.html

> Also, what's with using unofficial Python builds by default? Even on platforms where official builds exist (macOS/Windows)? I get that these standalone builds solve certain problems (like bootstrapping), but it feels like a risky shortcut. If those unofficial builds go unsupported or change directions, where does that leave "uv"? Why not at least give users the option to rely on official binaries?

The official macOS binaries wouldn't work for uv because they're not portable. They're also taking ownership over the indygreg project which is a great thing for everyone since portable pythons are useful in a lot of contexts. I'm sure they'll start sending some of the portability changes upstream too once they get there.

I don't see how this is criticism.

I've settled into a mostly daily cadence. If there's a day with more than 1 it's because there is a relatively serious bug that I don't want anyone to need to wait around for—those are the releases you should actually pay attention to so you're not missing something important. It's true I used to do more but I've dialed this back in recent weeks.

That said, it's a selfish strategy that benefits me more than anyone. It ultimately means I don't spend as much time fixing bugs since resolutions go out quicker and users get to test them (often whether they want to or not) while the issue is fresh in my head and I can quickly make an adjustment if needed.

I know especially package maintainers such as yourself would prefer I have nightlies for this purpose and then less frequent releases but that's more work for me and means users generally will be testing changes with a bigger delay.

Users may also think they want this but I actually think it wouldn't serve their interests—it'd mean I spend less time actually improving mise and more time with logistics. I'm also terrible at release notes and commit messages and I'm not sure it's an area I want to improve in simply because that would come at the cost of doing other things. I also don't like doing that stuff and this is (ostensibly) a hobby after all.

That said, I'd really appreciate if you came by our discord and had a conversation about this with me. While those are my reasons for the way things are I'm also certainly not opposed to change. With homebrew I have a release hook to automate this process and perhaps we could do something similar for MacPorts. We could even automate every N releases or something if you think that would be better.

> And where are those mystery meat binaries supposed to come from?

the vendor

I try not to be annoying best I can, but in the `mise trust` case I had to opt for tightening security even if it meant a bit of friction.

I really appreciate that. It's definitely something I get a ton of satisfaction about of building. Drop by our discord and let me know how it goes!

I don't understand how people don't notice the massive tax they're paying by using nvm:

    $ hyperfine "~/.nvm/nvm.sh" "mise env"

    Benchmark 1: ~/.nvm/nvm.sh
      Time (mean ± σ):      1.722 s ±  0.032 s    [User: 0.064 s, System: 0.112 s]
      Range (min … max):    1.684 s …  1.805 s    10 runs
     
    Benchmark 2: mise env
      Time (mean ± σ):      13.4 ms ±   5.7 ms    [User: 10.0 ms, System: 21.3 ms]
      Range (min … max):     9.4 ms …  42.2 ms    29 runs
      
    Summary
      mise env ran
      128.14 ± 53.94 times faster than ~/.nvm/nvm.sh

100x is definitely something you'll notice

EDIT: for some reason in discord we're getting very conflicting results with this test. idk why, but maybe try this yourself and just see what happens.

you should see this in tomorrow's release, or you can install with cargo from main branch now: https://github.com/jdx/mise/pull/3414

it's very possible, I don't recall when/why I added it

system updates causing breakages with mise tools would be news to me

I wonder if you misunderstood what mise is based on your mention of "packaging challenges". mise deals with language runtimes and dev tools—it doesn't manage dependencies or package anything.

I often hear suspicion about mise for this reason from people that haven't used it. I suppose it's not surprising. That said, I have spent over a decade in the developer productivity space as well as hundreds if not thousands of hours working on mise in the last 2 years—if there is someone that can build this I'm probably the right guy for the job.

Particularly with dev tools, it's long been the case that mise has solved this problem. Improvements are continuing to be made with things like improving supply chain security and ergonomics with python—though it's not like the python community itself has its DX figured out.

Of course I'm still fixing bugs pretty regularly and that probably won't ever change but there are hundreds of thousands of developers out there using mise (kind of a guess, but I'm pretty sure) and it's working great for them. It's in the top #100 tools in homebrew now: https://formulae.brew.sh/analytics/install-on-request/30d/

This definitely isn't some scrappy project—I've devoted much of my life to this problem and I think all evidence points it it being a resounding success.

if you use asdf you can drop mise right in and it'll work the same but faster and with better supply-chain security. people have been doing this for almost 2 years and mise fits that use-case perfectly.

You don't have to touch the env vars and tasks stuff.

node is used in a lot of the examples (because it's popular) but mise is written in rust and certainly doesn't require node

there's a list with common commands you might want to run: https://mise.jdx.dev/walkthrough.html

if you post an issue/discussion about the python thing I'd love to investigate it a bit

there is a `mise generate github-action` command which uses https://github.com/jdx/mise-action

not sure I understand what you mean by "mise steps (having to rewrite / unable to use dependencies etc)."

I wrote a detailed comment yesterday about this: https://news.ycombinator.com/item?id=42353634

tl;dr: mise has more functionality like parallel tasks, watching for changes, and comprehensive argument parsing support (including custom autocomplete)

the biggest difference is the syntax. just is more concise and you really need to learn the syntax in order to use it. In mise things are more verbose but I feel easier to read for someone unfamiliar with it.

I think the entire concept of nix is a broken model not fixable by docs and better DX. Precompiled, portable binaries are the way to go which is what mise is built on. Trying to maintain this separate build chain where everything is compiled in a sandbox gives your system a "split-brain" problem where you have the "nix world" and the "macos (or whatever) world". Ultimately, this just causes problems. Of course I'm ignoring NixOS but that's a sledgehammer for this supposed "problem" nix is trying to solve in the first place.

mise is for the 90% of developers that just want things to be fast and work and don't care about the nuts and bolts.

lmk if there might be a way I can help with that, I don't think anyone's posted an issue about jetbrains issues—not for a long time at least

I started writing mise in a bout of frustration after trying to use nix

there isn't a hook for executing shell source, but it would be possible to add I think. The current hooks already execute inside of a shell function so there would just need to be a way to declare that you want a hook to run inside the shell, maybe like this:

    [hooks.enter]
    shell = true
    run = ". completions/mycli.sh"

I made an issue if you'd like to track: https://github.com/jdx/mise/issues/3412

in mise you wouldn't need that preamble. `set positional-arguments` is just how it behaves normally and `mise run` doesn't just show available commands—it's also a selector UI

I think you'd like what I've done with mise. You can have tasks in your global config (~/.config/mise/config.toml) which by default are shown no matter where you are. `mise run` will show a selector by default of all tasks available, so no need to manually setup fzf. Shebangs work the same. Commonly, mise users would also put "uv" into their config so other users don't need to set that up separately from mise itself.

Interactive inputs are something I'm planning on shipping relatively soon. It would not be hard to do—I've got the ui components to do it and the data model supports it.

you can do that too: https://mise.jdx.dev/environments.html#env-file

but sometimes you don't want to make it an env var—just supports this too through the `export` keyword