[HN Gopher] Mise: Dev tools, env vars, task runner
___________________________________________________________________
Mise: Dev tools, env vars, task runner
Author : ksec
Score : 185 points
Date : 2024-12-07 07:21 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jindongz wrote:
| Finally I can retire makefiles in my python projects
| zero-g wrote:
| Justfile[0] was a more familiar makefiles replacement for me
|
| [0]: https://github.com/casey/just
| konradb wrote:
| Have enjoyed replacing makefiles with https://taskfile.dev/
| which looks like it could be more powerful due to being able
| to detect changes etc. But glad Just has been good.
| spott wrote:
| Just curious: what do you use make for in python projects?
| MadsRC wrote:
| Not the parent, but I use it for projects (including Python
| projects) to run tests, code generation etc. when I can't use
| mise.
| whilenot-dev wrote:
| As a task runner. What do you use?
| devjab wrote:
| I'm not GP but I use poetry. Can't even imagine working
| with Python without it.
|
| https://python-poetry.org/docs/cli/
| nxpnsv wrote:
| You might enjoy https://poethepoet.natn.io/ it makes
| tasks easier, and you don't even need poetry to benefit
| from it (I use it with UV these days)
| spott wrote:
| I can't imagine going back to poetry after using uv.
|
| uv is like 10x faster than poetry for installs and
| dependency resolution.
| spott wrote:
| Just.
|
| It is a less heavyweight make. Similar syntax and behavior,
| no .PHONY, a couple of helper functions and behaviors. It
| is designed as a task runner rather than a build system.
| ashishb wrote:
| If not makefile then what do you use for a project that has
| Python for backend and JavaScript for frontend? Does everyone
| learns all the tools or do you just provide a 'make lint'
| that works in all codebases?
| aaronbrethorst wrote:
| I recently switched to Mise for all of my JS, ruby, python, and
| java sdk management needs, and I've been delighted with it so
| far. Not having to install RVM, NVM, some toxic brew of python
| installers until I get a working python environment, and SDKMan
| has been such a breath of fresh air.
| Zaloog wrote:
| `brew install uv` and no more python troubles occur
| syhol wrote:
| `mise use uv`, there, I fixed it for you.
|
| Mise actually has a great integration with uv, like auto venv
| activation.
| semi-extrinsic wrote:
| I think uv has auto venv activation and workspaces and
| stuff, now that uv is the official successor of Rye?
| sureglymop wrote:
| This is nice! Jetbrains tools sometimes need a bit more
| configuration with it, otherwise it's very seamless.
| MadsRC wrote:
| I find the JetBrains integration spotty - I have to run 'eval
| "$(mise activate)"' in every terminal session for it to pick up
| the env. I have vague recollections of also having issues with
| running executables from the IDE as it is missing the env
| details.
|
| The SDK discovery works great though :D
| hinkley wrote:
| I believe, and I could be wrong about this, that JetBrains
| only picks up changes to your .shell_rc files on a restart.
|
| What I learned instead was to stop using the built in
| terminal in WebStorm. If WebStorm crashes you're fucked.
| Objectively, it never did that a lot and does less so
| recently, but not never.
|
| WebStorm likes to pick up file system changes when you give
| it focus, so any manipulation you do in the builtin terminal
| doesn't necessarily do that.
| jdxcode wrote:
| 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
| hv42 wrote:
| There is a plugin that works well to automatically configure
| some of the SDKs
| https://plugins.jetbrains.com/plugin/24904-mise
| syhol wrote:
| I'm using it to unify my teams toolchain without resorting to nix
| or running everything in docker.
|
| I still use docker to run services and I still like the idea of
| nix, but the DX of mise is too good. Tasks are really nice too,
| all my repo scripts now have completions.
| aiono wrote:
| Did you try https://devenv.sh/? It uses Nix under the hood but
| with an improved DX experience. I haven't used it myself
| personally since I find Nix good enough but I am curious if you
| would still choose mise over devenv.
| konradb wrote:
| I'd be interested in anybody who has tried https://devenv.sh/
| and https://www.jetify.com/devbox and chosen one over the
| other. Tried devbox which has been good, but not devenv.
| yawaramin wrote:
| We are starting to adopt devenv in our team. Overall it's
| really good--we have control over our toolchain, environment,
| and the processes that we start. There are some lingering
| papercuts though, like they haven't yet released a version
| where they allow specifying the Go toolchain version, and
| they seem to periodically re-download the Nix package
| archive. But I think they are improving fairly quickly.
|
| Ultimately, we might still end up moving to straight Nix
| flakes, just not sure yet.
| pxc wrote:
| > they haven't yet released a version where they allow
| specifying the Go toolchain version
|
| Devenv's maintainers are friendly and responsive when it
| comes to contributions from downstream, and like 90% of the
| devenv repo is plain ol' Nix code written in idioms that
| are common in the community.
|
| I mention it because my team has hit some papercuts as
| well, but I've been really happy with how easy it's proven
| to address them. :)
| yawaramin wrote:
| I agree, the fix is in the main branch, they just haven't
| released it yet. It's just that the existing released
| versions just don't allow customizing the Go version
| because of some hardcoded assumptions in the Nix code. So
| I'll wait for the released version. I did say these are
| papercuts, not showstoppers ;-)
| syhol wrote:
| I briefly tried devenv and I find it much easier to use than
| raw nix, but I also had issues with my nix install on macos
| (using both the official and the DS installer). It worked
| well on my linux machine.
|
| Today though mise has so many other great features, I would
| still choose it over devenv or devbox.
| mootoday wrote:
| I've used Devbox for two years for my projects and any work
| I've done for my clients.
|
| I'm curious what some of the mise features are you like.
| syhol wrote:
| I like Devbox and I'm familiar with its features so I'll
| just mention the extras the mise has.
|
| The ubi backend means I can use nearly any binary
| published on GitHub without needing to worry about a
| flake or nixpkgs. Just get the binary directly from the
| author. Same for many of the other backends
| https://mise.jdx.dev/dev-tools/backends/.
|
| Tasks are very powerful, they can use dependencies,
| flags, args, completions, and watches. Also can be
| defined either as strings in the config or point to shell
| scripts or even python/node/whatever scripts.
|
| The shebang trick is very fun for writing portable shell
| scripts https://mise.jdx.dev/tips-and-tricks.html#shebang
|
| The fact that mise doesn't depend on nix is both a
| blessing and a curse. I have less tools available and I
| don't have the power of a package manager, but on the
| flip side I don't need to deal with the idiosyncrasies of
| nix.
| mootoday wrote:
| Thank you, TIL about ubi! My brain is now compiling a
| list of places where this will replace either a shell
| script or flake for my projects :).
|
| Tasks sounds similar process-compose which is bundled
| into Devbox. I'll have to read up more on tasks though to
| see if that's an accurate assessment.
|
| Nix is definitely a double-edged sword... One thing I
| like about Devbox is that it keeps Nix mostly (!) out of
| sight, mostly unless I want a binary from a GitHub
| release :).
| mongol wrote:
| I use direnv but miss that it can't initialize bash completions
| as I enter a directory. Can mise do that?
| jdxcode wrote:
| 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
| mongol wrote:
| Very helpful! If this can be made to work I may switch from
| direnv
| jdxcode wrote:
| 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
| 0xbadcafebee wrote:
| I don't really understand why people use direnv, but you could
| easily replace it with a shell script that could load anything
| you want when entering a directory.
|
| You basically just write a script that hooks into your shell
| (using your shell's existing hooks, like PROMPT_COMMAND for
| bash) and have it load a shell script in any directory you
| enter.
|
| Obviously this is a security risk, as you could enter a
| directory controlled by a hacker. This is why (presumably) they
| only deal with exported variables, though even that's
| dangerous.
| PufPufPuf wrote:
| ...or you could use a tool somebody already wrote, which even
| includes a security mechanism.
| ghthor wrote:
| Direnv can do this, but currently only for bash shells and
| maybe only when using nix flakes. There is an open issue to get
| zsh working, but I just stick to bash TBH
| mongol wrote:
| I didn't know this. I know this ticket is open
| https://github.com/direnv/direnv/issues/443 but it is not
| clear to me if it is working for bash
| aiono wrote:
| This is already a solved problem with Nix shell (except the task
| runner part). I don't understand why there are any other
| alternatives still being developed. Nix supports more packages
| than any other solution, it's battle tested and cross platform
| (didn't try on Windows but on Mac OS it works fine). And it's
| more reproducible than any other package manager.
| bloopernova wrote:
| Because some people may not want nix. Mise is, in my
| experience, much easier to get into and start using.
| jdxcode wrote:
| I started writing mise in a bout of frustration after trying to
| use nix
| lifty wrote:
| thank you!
| yawaramin wrote:
| Have you tried devenv? What do you think?
| jdxcode wrote:
| 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.
| max-privatevoid wrote:
| If only they were actually portable. As it stands, mise
| is just another half-solution, and you can't solve the
| other half of the problem by ignoring it.
| yawaramin wrote:
| Don't you kinda need to separate the worlds to avoid
| borking your system when you update? Eg macOS decides to
| ship some customizations in its curl,[1] and now you need
| your own curl because Apple's customization is breaking
| your project?
|
| [1] https://daniel.haxx.se/blog/2024/03/08/the-apple-
| curl-securi...
| jdxcode wrote:
| system updates causing breakages with mise tools would be
| news to me
| lijok wrote:
| Because Nix has dogshit UX and the team seem to be completely
| oblivious to it regardless of how many times it's brought up.
| max-privatevoid wrote:
| Well, "dogshit UX" isn't exactly actionable, is it?
| lijok wrote:
| Oh it absolutely is !
| max-privatevoid wrote:
| Care to give some examples?
| lijok wrote:
| Use it as a signal to start an investigation into how
| many agree with that sentiment, try to measure the
| resulting adoption dropoff, and use those stats to push
| for a UX redesign.
| Valodim wrote:
| This is a pretty ignorant stance. It implies that the
| issues would somehow be easy to address if they were just
| acknowledged. Are you aware of the efforts that have been
| put into this so far? Have you considered that achieving
| the vague improvements you are asking for, working on a
| groundbreaking technology while holding together a
| rapidly growing community, is just really hard?
| lijok wrote:
| Can you clarify how you arrived at the conclusion that I
| was implying fixing the UX is easy, or where you saw me
| asking for "vague improvements"?
|
| While we're on the subject, I can assure you, Nix is far,
| far from groundbreaking tech.
| nextaccountic wrote:
| I really want nix to succeed, but it has terrible UX and
| documentation. It also doesn't help that the community is still
| fighting over whether flakes should be a thing.
| hinkley wrote:
| Every time I've used a declarative system at work I either
| eventually become one of the experts and we all have lines
| outside our door of people who just don't get it, or I
| replace it with something imperative so we can all get some
| fucking peace.
|
| Ant was by far the most stressful. I had to cyberstalk James
| Duncan Davidson to understand what he was thinking. The
| mental model for the tool wasn't in the docs. It was in forum
| posts spread across three+ different websites. And it was
| slightly insane. First writer wins broke everyone's brains
| across three jobs before someone helped me kill it and
| replace it with something else.
|
| It's also a cornerstone of my thesis: never trust software
| someone says they wrote on an airplane. That's not enough
| time to create a good solution, and any decision you make
| while experiencing altitude sickness is sketchy. (Prior to
| 2010, airline passengers were experiencing 8000 ft atmosphere
| on every flight. One of the selling points of the 787 was
| 5000 ft equivalent pressure)
| crakhamster01 wrote:
| > It also doesn't help that the community is still fighting
| over whether flakes should be a thing.
|
| Could you elaborate on what the debate is? Haven't heard of
| this before!
| klysm wrote:
| Docs are terrible, writing new packages is difficult, etc. It
| may be the right technical direction but the execution is
| lackluster
| ghthor wrote:
| Reading nixpkgs is pretty amazing info, better then any docs.
| But I actually think the docs are pretty fantastic. The
| manual is solid, the CLI help text is pretty excellent. I
| don't get when people say the docs are bad.
| pxc wrote:
| > This is already a solved problem with Nix shell (except the
| task runner part).
|
| devenv, a Nix+direnv-based solution, has a pretty cool task
| runner thing, plus service management.
|
| > I don't understand why there are any other alternatives still
| being developed.
|
| I love Nix and I believe it's a great choice for many teams,
| for the same use cases as mise. Nix's paradigm is the future.
| But Nix's defects are also real and obvious enough if you use
| it for long. I can understand why someone might see value in
| trying a fresh new effort, or an approach that asks less
| commitment.
| srid wrote:
| > This is already a solved problem with Nix shell (except the
| task runner part)
|
| The task runner part is also solved in Nix. See
|
| https://github.com/Platonic-Systems/process-compose-flake
|
| and
|
| https://github.com/juspay/services-flake
| lijok wrote:
| The name is absolutely perfect.
| helix278 wrote:
| What is the main difference with just?
| jdxcode wrote:
| 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.
| BiteCode_dev wrote:
| My experience with such tools is that when you do everything, you
| don't do anything right.
|
| The chances that it doesn't leak greatly the underlying
| abstraction and creates troubles to figure it out when it will
| invariably fail is zero.
|
| Because most people barely know in depth the packaging challenges
| for one ecosystem. In Python there are maybe a dozen in the world
| that have a good hang of __all__ of it.
|
| And the devs of this tool would need to know so many.
|
| Of course they don't, they wrap existing tools, which implies
| exactly what I said above.
| hinkley wrote:
| Example: I tried to convince our deployment system to deploy
| patch releases to simplify our hotfix solution. The code was in
| Node and the deployment tool in Python. I had to thread the
| needle to come up with a semver pattern that was legal in both
| Python and NodeJS. Not impossible but annoying. (Then
| discovered our deployment tool wasn't using the semver parser
| in Python and it still didn't work. Goddamnit.)
| n144q wrote:
| Exactly. A task runner for Node.js is already complex enough.
| And it's not just a task runner itself, but rather an ecosystem
| of things working together. Now you tell me this can somehow
| handle Node.js, Python and others. I'll need to see how it
| actually works in the real world to believe the claim.
| rsyring wrote:
| I think mise gets a lot right. I use it for environment
| variables, Python virtualenv creation and activation, and task
| scripts.
|
| I've been a software developer for over twenty years and am
| usually reluctant to use new tools. But mise has been a
| fantastic addition to my dev workflow.
| stavros wrote:
| I have two problems with Mise: There isn't a page with the
| most common commands I might want to run, and whenever I try
| it, some Python imports mysteriously fail. Then I disable it,
| and everything is fine again.
|
| I might be motivated to persevere if I only had one of the
| above problems, but with both of them together, it's too much
| of a hassle.
| jdxcode wrote:
| 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
| stavros wrote:
| Oh, is that the page that resulted from the issue I
| opened? It looks good, thanks!
|
| I'll open an issue for the Python thing, I can reproduce
| it reliably.
| jdxcode wrote:
| it's very possible, I don't recall when/why I added it
| rsyring wrote:
| If you want to post a discussion on the mise GH repo, I'd
| be happy to help. Feel free to @ me in that discussion so I
| don't miss it.
| stavros wrote:
| I posted an issue about the documentation and I see that
| it was added, so thanks! If you want, I can post more
| issues of the type "as a new user of mise, I expect to be
| able to do _______ but I can't see how in the docs". I'll
| also post about my Python issue when I reproduce it next.
| PufPufPuf wrote:
| Your experience with "such tools" covers experience with Mise,
| or are you just making assumptions?
|
| My experience with Mise is that it's a great tool.
| coldtea wrote:
| > _My experience with such tools is that when you do
| everything, you don 't do anything right._
|
| Does it matter? Even dedicated tools don't do everything right.
|
| As long as it does the things one wants to do good enough, and
| offers a cohesive interface to them...
| jdxcode wrote:
| 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.
| nlh wrote:
| I have to say, I've been reading your replies here (and your
| big reply in the just thread) and I'm super super impressed
| with your dedication to this project. I can tell just in how
| you write, the volume of responses in this thread, and your
| tone that this is a real passion project and you're deeply
| serious about this. I love seeing this. Thanks for your
| dedication!
|
| (And now I'm off to go try mise....)
| cstrahan wrote:
| > Because most people barely know in depth the packaging
| challenges for one ecosystem.
|
| I think you're greatly overstating the problem, at least
| insofar as it relates to this tool.
|
| For example, Python has its prefix (where packages are
| installed) baked into its installation. pip, ux, poetry --
| whatever -- are going to install python packages there.
|
| This tool is unconcerned with package installation -- it is
| _only_ concerned with getting the interpreters installed and
| managing which one is on your $PATH.
|
| There's literally nothing to leak.
|
| And regarding "wraping existing tools" as proof of some
| shortcoming in mise (and/or similar) -- if they reinvented the
| wheel, _that's_ where things could leak. And separation of
| concerns is a _good_ thing.
| shepherdjerred wrote:
| It might be useful for you to try the tool before complaining
| about it
|
| I've used mise for years. It works perfectly well. I use it for
| Go, Node, Deno, Java, Python, Ruby, and Rust.
| dmarinus wrote:
| Lately I was thinking "what's the best way to integrate/use a
| task runner like mise in a github actions workflow".
|
| Looking at the workflow files in the mise repository it seems
| like they gave up and just put in a few run: mise steps (having
| to rewrite / unable to use dependencies etc).
|
| I think it would be better if you could generate the workflow
| files but I haven't found such a project yet.
| jdxcode wrote:
| 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)."
| DrBenCarson wrote:
| Just using mise as a drop-in asdf replacement has been delightful
|
| Same functionality but much snappier with better ux
| PittleyDunkin wrote:
| Tbh just having to install node ensures I'll never use this. At
| least use something like python that's already on my system!
| jdxcode wrote:
| 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
| mirashii wrote:
| You don't have to install node, or Python. mise is written in
| rust and distributed as a binary.
| PufPufPuf wrote:
| What gave you the idea that it needs Node?
| PittleyDunkin wrote:
| Poor reading comprehension; I read "The following shows using
| mise to install different versions of node." as "The
| following shows using node to install different versions of
| mise."
| banseljaj wrote:
| What are you talking about? You don't need to install node for
| this. It's a self-contained rust binary.
| 0xbadcafebee wrote:
| I'm not "a developer" so I never got the use case of tools like
| these. Instead I just use the stuff they mention (asdf, make).
|
| I use Asdf to manage versions of all programs in a monorepo.
| Works great (well, actually asdf's UX is terrible, but it works
| reliably, and the plugin design is great).
|
| For development, I don't ever load environment variables into my
| current shell session. I run a script or Makefile which loads any
| necessary variables, does a thing, and then exits. It would be a
| nightmare to have to constantly check if my current shell session
| had X variable in it.
|
| I use Make for repeatable small commands that will vary per
| directory, or for simple parallelizing or ordered execution of
| commands. I have a big one that handles Helm installs, and a few
| more for Terraform, Packer, asdf, etc. I also use them for
| deployments in hierarchical environment directories, where
| environment variables are loaded from parent directories. I love
| that Make has all the features it has, because I always find
| myself eventually reaching for something you don't find in "just
| a task runner", and it makes my life easier.
|
| I use shell scripts when I need to make a composeable tool
| that'll be slightly longer or more complicated than a Make target
| should be. I have saved so much time and effort writing these
| tools in shell rather than Python or something, where there is
| inevitably way more bugs and dependencies. The only time I have
| needed to use something more complex than shell is when I have a
| lot of APIs to deal with that also deal in JSON; if it's a lot of
| complexity it's better than curl/jq, but if it's only one small
| task, curl/jq is better.
|
| The end result works great. The whole environment just needs asdf
| installed (from Homebrew, for example). With stock Make and the
| stock Bash v3, I can manage everything automatically,
| everything's version-pinned and automated, all variables get
| loaded at runtime as needed, and the whole thing can be grokked
| by just reading some simple Makefiles.
|
| The only thing I want to fix now is to get rid of the superfluous
| Makefiles from directories (they're all symlinked back to one
| Makefile). It's a pain to re-symlink them all when I change
| directory structure. Probably should just write a script for
| it...
| jdxcode wrote:
| 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.
| hv42 wrote:
| I think you should give `mise` a chance. I believe it can help
| improve your workflow.
|
| It's better at managing tools than `asdf`, very close to
| `direnv` and superior to `make` as a task runner (more verbose
| but much easier to understand). One of the advantages is that
| `mise` tasks can be standalone files (you can even write file
| tasks in python if you prefer, see
| https://mise.jdx.dev/tasks/file-tasks.html)
| PufPufPuf wrote:
| I use Mise as a drop-in replacement for asdf. It's fully
| backwards compatible with .tool-versions and other config
| files, and unlike asdf it uses a PATH-based approach instead of
| shims.
| syhol wrote:
| All the features are opt-in. I started using mise because I
| wanted something like asdf only without the bad UX, and mise
| can use asdf plugins.
|
| For env vars, you don't need to load them into your shell if
| you don't want to. When you run a task, mise will make sure the
| env vars in your config are set, so thats not something you
| need to worry about.
|
| I still use shell scripts like you describe, mise just
| supercharges them a bit. When I need to make sure my teammates
| have the tools in that script (like jq) installed, mise just
| ensure they are installed before running the command, as long
| as you declare them in your tools list.
|
| If your setup works for you thats great.
| whydid wrote:
| Why do JavaScript programmers call ini files "environment
| variables" ?
| Izkata wrote:
| Environment variables are key/value pairs that are passed from
| parent process to child process when the child is first
| created. A convention has also arisen where these can be put
| into environment files so the overarching system (for example,
| docker) can load them from a consistent place (without having
| to add them to your shell and risk leakage across projects) and
| then pass them down to child processes in typical environment
| variable fashion.
|
| Also there are no sections like there are in ini files.
| cstrahan wrote:
| They don't.
|
| I'm guessing you navigated to the
| https://mise.jdx.dev/environments.html page and saw the TOML
| syntax (which looks an awful lot like INI), and confused
| yourself.
|
| Mise (like a _lot_ of software) uses TOML as the format for its
| config files (as opposed to something like JSON). Mise reads
| that config, to automatically export environment variables on a
| per directory tree basis.
|
| When the docs refer to environment variables, they very
| literally do mean environment variables. The values of which
| are taken from a format that resembles INI, as you have
| noticed.
| harha_ wrote:
| All that complexity, for what?
| PufPufPuf wrote:
| Having to manage Python / Ruby / Node etc. versions by hand is
| less complex?
| gavmor wrote:
| For me, this competes with asdf.
|
| Otherwise, it would compete with eg nvm, rvm.
|
| I haven't managed versions "by hand" for over a decade.
| PufPufPuf wrote:
| Ignoring the task runner stuff, Mise is great just as a "better
| asdf". It allows many more package sources (including pipx, go
| and cargo), and it puts the actual executables on PATH -- not
| shims like asdf, which has a tendency to break stuff.
| mootoday wrote:
| I read the project's Readme and all I'm left with is "why?".
|
| I use Devbox[1] and get access to the entire Nix ecosystem, done.
|
| [1] https://github.com/jetify-com/devbox
| Zizizizz wrote:
| Mise just works and takes maybe 1-2 minutes to explain and have
| a tool running on a team members machine in my experience. I
| couldn't get into nix, too complicated for me and I've yet to
| find a resource that makes it click for me. After that I would
| feel comfortable encouraging the rest of the team to use it but
| as mise is so easy and even more popular, I will probably just
| stay using this. I will look into devbox though, thank you for
| the recommendation!
| banseljaj wrote:
| I started using mise back when it was still called rtx. I was a
| little annoyed by asdf's quirks and having it replicate that
| behavior while being faster and less intrusive in my shell
| configuration was great.
|
| Since then, mise has folded in two capabilities that I needed the
| most: Task Running and Env Vars.
|
| Overall, it has been a fantastic experience for me. I love how
| the developer has spent a lot of time ensuring compatibility with
| existing tools while still building future capabilities.
|
| I will add one thing that I knew I needed but couldn't find
| anywhere was added through the recent backends feature. I do a
| lot of trust and R development and there are dev tools that I
| need installed that I don't use as libraries, just the binaries.
| It was a problem making sure that those dependencies were
| installed in a new environment. Now, it's just so easy: I list
| those in my `mise.toml` file, and that ensures they are installed
| and installable.
| tecoholic wrote:
| The biggest visible boost has been in my shell startup times.
| Buying a computer after 5 years with 4 times as many cores and
| it feeling just as sluggish because nvm and pyenv are parsing
| the same set of bash files reading from disk was not pleasant.
| Mise actually made me feel, I didn't just throw the money into
| a void
| jdxcode wrote:
| 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 +- s): 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 +- s): 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
| ducdetronquito wrote:
| It's a simple tool that makes my life easier for more than a
| year: thanks to the creator and contributors :)
___________________________________________________________________
(page generated 2024-12-08 23:00 UTC)