[HN Gopher] Install Asdf: One Runtime Manager to Rule All Dev En...
___________________________________________________________________
Install Asdf: One Runtime Manager to Rule All Dev Environments
Author : jdsalaro
Score : 116 points
Date : 2024-04-28 04:36 UTC (18 hours ago)
(HTM) web link (jdsalaro.com)
(TXT) w3m dump (jdsalaro.com)
| thedookmaster wrote:
| I've used asdf for years, but recently switched to
| https://github.com/jdx/mise It's a drop-in replacement for asdf,
| but I prefer some of the nice features it has to offer.
|
| See: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
| quickslowdown wrote:
| I recently started using https://github.com/prefix-dev/pixi for
| Python projects. I really love it so far, but this tool looks a
| bit more mature, which makes sense considering pixi is
| relatively new.
| jdsalaro wrote:
| > I recently started using https://github.com/prefix-dev/pixi
| for Python projects
|
| Why is it based on the Conda ecosystem? Do you happen to
| know?
|
| I assume it's for portability, but that sounds heavy.
| abkfenris wrote:
| For as much improvement as there has been with what can be
| distributed via PyPI, there are still some domains that
| have gnarlier dependencies than wheels happily handle
| alone, and you either need to reach for the system package
| manager (and loose the ability to really control the
| dependency environment from that mismatch), or take
| advantage of the Conda ecosystem.
|
| My org does a lot of work combining machine learning with
| oceanographic and climate modeling, which are both domains
| that have deep dependency chains that don't always mesh
| well, especially as our researchers mix in R and other
| languages as the same time, and the Conda ecosystem helps
| us a ton with that, but there are issues that `conda` and
| `mamba` don't help us out with.
|
| Pixi takes a swing at some of what the Conda ecosystem
| hasn't been great at (at least without a lot of manual
| custom ceremony) that Cargo, Poetry, Pipenv, PDM, and other
| dependency and workflow management tools have demonstrated
| can be done such as lock files, cross platform dependency
| management, task running, and defining multiple related
| environments.
|
| What's really cool when you have a mix of projects, Pixi
| can work almost entirely PyPI native out of a
| `pyproject.toml`, other than installing Python from Conda-
| Forge, so you can mix and match environments but stay with
| the same tool.
| https://prefix.dev/blog/using_python_projects_with_pixi
| docs: https://pixi.sh/latest/advanced/pyproject_toml/
| bmitc wrote:
| Why this over Poetry?
|
| asdf handles tools, not really packages. So asdf would
| install Python and not Python packages.
| jdsalaro wrote:
| My experience with Poetry has been mixed the last couple of
| times I've tried it, it attempts to do way to many things
| but often failed to do them properly. Determining
| dependencies and proper packaging and upload to PyPI are
| the ones which come to mind.
|
| asdf.vm together with pipenv is my go-to for Python
| environment management.
| eddyg wrote:
| pip-tools[0] is all most things need IMO. It's a great
| balance of simplicity and utility.
|
| [0] https://pip-tools.readthedocs.io/en/stable/
|
| As for Poetry, it is constantly improving and has gotten
| _very_ popular. It should not be dismissed, especially
| for larger projects since its dependency management is so
| much better than pipenv. This is a good primer:
| https://diegoquintanav.github.io/poetry-primer.html
| appplication wrote:
| pyenv + pip tools is all one needs. Supposedly uv is
| gunning to be a drop in for both. I think there's a good
| chance uv pulls it off and becomes defacto for this use
| case.
|
| I think it's fair to see appeal in poetry, but ultimately
| the maintainers have created a culture that feels a bit
| too non-collaborative to outside ideas or use cases
| beyond what they more narrowly envisage. That said, my
| perspective may just be tainted by multiple poor
| experiences interacting with the maintainers.
| jdsalaro wrote:
| > pyenv + pip tools
|
| then you'd also need rbenv, nvm, etc.
|
| and pyenv can implode in marvelous ways.
| appplication wrote:
| I can't speak to rbenv or npm, but IMO it's better of use
| well known and canonical tools for each rather than a
| more unknown mega tool that wraps or replaces these.
|
| pyenv isn't perfect, and isn't what I'd use for prod
| images, but for dev setup it's relatively bulletproof and
| less issue-prone than any alternative I've seen.
| cholindo wrote:
| +1
| oakesm9 wrote:
| I did the same. mise is brilliant! For reference it was
| previously called rtx
|
| The main differences are better UX with simpler commands and it
| not using shims, which means much better performance
| chem83 wrote:
| mise borrows the plugins from asdf, which also makes it non-
| cross platform. Interesting discussion on this topic on their
| GitHub: https://github.com/jdx/mise/discussions/66
|
| Solutions considered include adopting the vfox plugin system
| or transpiling all asdf plugins to ShellJs.
|
| Now I know that vfox exists.
| jdxcode wrote:
| I made some progress on windows last week! I'm working on
| making it so vfox plugins can be used as the "default"
| backend instead of asdf which will be a prerequisite for
| windows support. Step 1 is being able to run vfox plugins
| inside of rust which I got pretty far on:
| https://github.com/jdx/vfox.rs
|
| It'll be a long road ahead and I could certainly use some
| help if anyone out there is interested in moving it
| forward. That said, vfox is a really great project and they
| are targeting windows specifically. Windows will probably
| always be second in the mise ecosystem (because I don't use
| it) but my hope is I can get at least a baseline of support
| which would help teams that have occasional windows
| constributors.
| abrookewood wrote:
| Ah - was just about to come and post exactly the same thing.
| Mise is fantastic, supports everything ASDF does and is faster.
| roylez wrote:
| I still prefer asdf. It does the job just fine. Direnv has its
| own stdlib, which sometimes I find useful, and make is
| something I have to install anyway.
| jdsalaro wrote:
| I was only vaguely aware of rtx, but after discussing this
| post at length with people online they've made me aware of
| the rebranding and the general capabilities of mise.
|
| It sure is great, it is! However, like you, I tend to prefer
| minimalistic and predictable tools.
|
| That's why I decided to add the small comment in the
| discussion section of the post, to be fair but also kind of
| clear that bloating the runtime manager that was supposed to
| help manage the bloated runtimes and package managers isn't a
| great idea.
|
| Having said that, if the scope of mise stabilizes and it
| doesn't turn into a kitchen-sink kind of project, it sure
| seems sweet!
| johnathon023 wrote:
| Mise's #1 objective is to be a really great tool manager,
| just like ASDF, but way faster and smarter.
|
| However, it turns out that a tool that needs to be
| extremely CWD-aware also makes a great .env tool and task
| runner. I was also a little skeptical, but it's actually
| super super useful. Especially because it's easy to
| convince team members to install it for the tools, they get
| the rest for free with easy syntax.
| jauntywundrkind wrote:
| Mise/rtx doesn't cut it for us. It's approach is shell-based,
| so if your programs launch sub-processes, mise won't be
| applied. So for example Node scripts running in version 18
| might _npm run_ a process, which gets launched with the system
| node.js version.
|
| Where-as asdf creates shims that go into the PATH. That way any
| processes launching processes using normal env rules have asdf
| applied.
|
| Mise looks well built & is very fast. But it's jaw dropping to
| me that it's coverage is so drastically lower than asdf.
| bin_bash wrote:
| you can use shims with mise
| shepherdjerred wrote:
| +1
|
| I switched from asdf to mise and everything works fine _if_
| you setup shims.
| e12e wrote:
| Thank you for pointing that out - that means I can actually
| use mise (probably).
|
| https://mise.jdx.dev/dev-tools/shims.html
| hk1337 wrote:
| No disrespect to mise but this what's so frustrating about the
| industry. Just as one starts getting popular, some people move
| on to something "better".
| mynameisvlad wrote:
| I mean you can apply this argument to just about anything, it
| isn't really unique to "this industry" or computing in
| general.
|
| People will generally change taste and likes/dislikes every
| few years.
| dorian-graph wrote:
| > Just as one starts getting popular ...
|
| asdf hasn't just started getting popular. It's been popular
| for a long time already. IIRC I started using it ~8 years ago
| (~2016). asdf has been around since 2014. I believe Mise
| (rtx) has been around for a couple of years already too.
| hk1337 wrote:
| Fair. Honestly, I hadn't heard of it until about a year
| ago, up until then I was using pyenv and rbenv
| independently.
| Mo3 wrote:
| Same here. Never heard of it until a few months ago when
| I got back into Ruby on Rails after 12 years.
|
| Also, contrary to the other comments in this chain I
| don't find it particularly slow..
| sgarland wrote:
| The main issue most people have with asdf is that it's
| annoyingly slow. Not unusably so, but just enough that it's
| irritating.
|
| I identified [0] the source for much of it (sub-shells and
| pipes) and began a PR [1], but became bogged down with BATS
| testing, and then found mise / rtx, so kind of lost interest.
| Sorry. You can always implement these if you'd like.
|
| [0]: https://github.com/asdf-
| vm/asdf/issues/290#issuecomment-1383...
|
| [1]: https://github.com/asdf-vm/asdf/pull/1441
| mplewis wrote:
| You don't have to stop using asdf if you like it.
| thiht wrote:
| It's normal to build new stuff based on the experience we got
| from what came before. If you like asdf, use asdf, there's
| nothing wrong with using it, and there's nothing wrong with
| wanting something "better" (depending on what "better" means
| for the user)
| fredrikaverpil wrote:
| I'm liking pkgx over asdf as it can activate project tooling upon
| cd'ing into a project folder.
|
| https://pkgx.sh
| jdsalaro wrote:
| it certainly looks interesting! I'm still not sure if "It's npx
| for everything else" is good marketing :P
|
| > can activate project tooling upon cd'ing into a project
| folder
|
| this probably can be replicated with zsh hooks:
| https://zsh.sourceforge.io/Doc/Release/Functions.html#Hook-F...
| johnathon023 wrote:
| Mise gives you basically the same capabilities but is scoped a
| bit better, I'd check it out.
| drewbitt wrote:
| Is it? On top of an asdf and direnv replacement, mise is also
| a task runner, an environment variable manager, has
| experimental backends for npm/rust/go/python etc to take over
| their global package installs, replaces core asdf plugins
| with rewrites they have to maintain, and more. If anything it
| actually fails to scope itself
|
| (Note: I like the tool)
| matsemann wrote:
| Because of the insanity of python versions, paths, wheels etc and
| tiredness of spending time getting poetry install to work for
| project X due to also needing a full rust and c++ toolchain for
| some dependency etc..
|
| .. I run everything for a project in a container. Each project
| then matches perfectly the container actually used in production,
| so if it works there, it also works on my machine. I just volume
| mount the project folder into the container so I can't edit files
| from my IDE, and then pycharm has ok support for remote
| interpreters.
| seivan wrote:
| Whish there were some CLI to speed up this process actually.
| Just cd:ing into a folder should pull everything down for you
| to run iex/irb/node/etc as if it was native but running through
| the container.
| jdsalaro wrote:
| this makes me itchy, pulling the whole internet without
| looking into your development machine sounds like a very bad
| idea. It's the equivalent of an IDE's "do you trust this
| project" but on steroids.
| elbear wrote:
| Nix with direnv does that, but without Docker.
| cqqxo4zV46cp wrote:
| Yeah. IMO, you don't need to go very far into OS-level
| dependencies before it just makes more sense to use Docker.
| asdf et al can try to smooth the experience out all they want,
| and they certainly make things better, but unless your
| developer machines are REALLY standardised, it's really
| building a castle on sand.
| jdsalaro wrote:
| just curious, have you tried using asdf.vm with pipenv ? I've
| never needed anything else and have yet to have any problems.
|
| A couple of moons ago I used Poetry, but gave up on it because
| it was so heavy and unfortunately would bug out often.
| matsemann wrote:
| Not tried pipenv, I'm a bit tied by what the company uses.
|
| I did try using something similar to asdf (can't remember the
| name, think it changed), but it still didn't really solve the
| problem of OS dependencies and things needing to be compiled,
| and the problems arising from me not running the same OS as
| the application would run on. A dockerfile solves that, my
| system is a carbon copy of the prod environment.
| jdsalaro wrote:
| > A dockerfile solves that, my system is a carbon copy of
| the prod environment.
|
| Yeah, that can definitely not be beat, if at all probably
| only due to comfort.
|
| > Not tried pipenv
|
| I've been meaning to put a tutorial out there with my
| workflow since forever, if I had it I'd point you to it.
|
| I recommend you give it a try if you get the chance, you
| might like it.
| codethief wrote:
| Not OP but I've been using asdf and Poetry together and have
| been pretty happy with my setup. What issues were you
| experiencing?
| pyinstallwoes wrote:
| Indeed, hence my name.
| tjoff wrote:
| Development inside a container is still pretty darn miserable
| though.
|
| Nice in theory but not worth it.
| comandillos wrote:
| Dont we have VSCode Dev Containers? That works impressively
| well
| tjoff wrote:
| We do, and they are pretty cool but incredible limited.
|
| For one, you have to limit yourself to vscode and/or other
| IDEs with this capability - which ought to be a dealbreaker
| right there.
|
| But then you still have issues around syncing permissions
| and paths inside+outside the environment. And that all your
| other windows have a different view into your project.
|
| That alone is another dealbreaker (which you can bandaid,
| but...).
|
| And then if you need access to USB devices, well for one I
| hope you are running linux but even then that is a frigging
| nightmare. And there is some headache balancing everything
| above with admin rights etc.
|
| Yes in theory it is perfect. In practice we are not nearly
| there and you quickly realize the effort to do this well is
| orders of magnitude more work than just running native.
|
| I still always have a container for continuous integration
| in a way that you can run it easily on your workstation and
| can be turned into a devcontainer and/or built manually for
| small fixes in an old project you haven't used in a long
| long time. Which is great!
|
| But for your main development? I really tried but it is a
| nightmare in disguise.
| bmitc wrote:
| > For one, you have to limit yourself to vscode and/or
| other IDEs with this capability - which ought to be a
| dealbreaker right there.
|
| You don't have to. There's a devcontainer CLI.
|
| https://code.visualstudio.com/docs/devcontainers/devconta
| ine...
| wudangmonk wrote:
| The sheer amount of wasted time is hard to comprehend. How many
| man-hounrs or rather man-centuries have we spent trying to make
| python fast and trying to install it?. We just keep on
| polishing that turd.
| noobermin wrote:
| Wait, not only is it called asdf leading to confusion, it
| literally is also a package manager of sorts just like the
| original asdf???
|
| I just tried googling it having not really used CL in a while,
| and apparently it was seo'd to the top of google results too?
| phinnaeus wrote:
| What's the "original asdf?"
| ReleaseCandidat wrote:
| https://asdf.common-lisp.dev/
| guenthert wrote:
| https://en.wikipedia.org/wiki/Another_System_Definition_Faci.
| ..
|
| (it's bit like Python stealing the name of a CL compiler ...)
| bmitc wrote:
| asdf is not Python specific.
| Y_Y wrote:
| Correct, asdf will work with other Common Lisp compilers.
| bmitc wrote:
| :|
| 000ooo000 wrote:
| One of my pet peeves with tooling these days is the completely
| random naming. Literally no effort made, whatsoever, to come up
| with something vaguely descriptive. Neovim plugins are the
| worst for this. They're comically badly named.
| out-of-ideas wrote:
| agreed, but i know firsthand words are hard, and names are
| more specific words and can be very hard (especially for
| developers) - esp with shorter names ,and will have a higher
| chance of a name collision
| brabel wrote:
| I raised this complaint before and learned that most people
| using the "new" one have never even heard of Common Lisp, and
| certainly not of its own "asdf" system.
| lispm wrote:
| And the possibility of using "Google" to check for name
| collisions seems not to be known...
| juunpp wrote:
| The possibility of existence of a "programmer" that is
| completely oblivious to Common Lisp is the really
| interesting phenomenon to ponder here. But hey, at least
| the article links back to Hacker News, Mastodon and Reddit
| so that we can all revel in ignorance. Surprised there is
| no Discord.
| doctorraags wrote:
| Is it just me that never even wants to get to the problems that
| asdf attempts to solve?
|
| That example in the article of managing multiple python 2.7
| versions sounds like a horror story.
| jdsalaro wrote:
| OP here, although I hoped I took an example that was relatable,
| it seems it wasn't as relatable as I expected.
|
| > Is it just me that never even wants to get to the problems
| that asdf attempts to solve?
|
| You aren't alone, the scenario isn't ideal. However, brew's
| Python installation on MacOS as are Debian's and Ubuntu's are
| _extremely_ brittle. You are one cask, formulae or apt package
| away from needing to do a weekend-long spelunking session or a
| full blown system re-install if you have deadlines.
|
| PyEnv is a pain to set up, and maintain, which is what I used
| in the years before as well as after Python 2 was deprecated
| and projects started slowly migrating to newer python versions.
|
| > That example in the article of managing multiple python 2.7
| versions sounds like a horror story.
|
| It is a horror story, but is very common.
|
| Have you tried to install and maintain Java, Kotlin and Graddle
| installations for a given project although your machine is not
| primarily a Java, Kotlin, Graddle box? That is a real
| nightmare, not so much with asdf.vm.
| brabel wrote:
| You shouldn't need asdf to work with JVM stuff. I would
| suggest learning how to use SDKMAN: https://sdkman.io/
|
| It will manage the JDK for you. Usage is basically this:
| # Install a JDK, that version is now default sdk
| install java <version> # Another one, it asks if you
| want to change the default sdk install java <another-
| version> # List available and installed versions
| sdk list java # Change which one you're using in this
| shell sdk use java <version>
|
| That's all.
|
| You can also manage Gradle/Maven installations with SDKMAN,
| but that's not necessary, usually, because most JVM projects
| include a "wrapper" script which downloads the needed
| Maven/Gradle version for you.
|
| This works regardless of whether your project also needs
| Kotlin/Groovy etc. as those are just managed by Gradle/Maven
| (the only exception I can think of is if you use Kotlin
| Multiplatform as that will depend on the platform
| dependencies as well).
|
| So once you know SDKMAN, you can manage any JVM-based project
| with just this: sdk use java <jdk-version-
| used-by-project> ./gradlew build # or ./mvnw package
|
| If you need to do anything else, you should complain to the
| project authors as this is really all you should need!
| e12e wrote:
| > If you need to do anything else, you should complain to
| the project authors as this is really all you should need!
|
| Sure. But you might need node for some front end build
| tool, or a language server for sql. Then you can use two
| version managers, or just asdf.
| steph-123 wrote:
| I like x-cmd because its package system is written in more
| compatible posix-shell and awk, resulting in much smaller loading
| and startup overhead. Additionally, x-cmd integrates with asdf
| and provides AI support, along with over 200 modules for various
| command enhancements
|
| See:https://x-cmd.com/pkg/
| steph-123 wrote:
| it portability
| pbowyer wrote:
| I've had nothing but problems with asdf and nodejs and globally
| installed tools like yarn reporting "Cannot find node". Perhaps
| global tools cannot be compatible I don't know; asdf reshim
| doesn't often fix it.
| jdsalaro wrote:
| there's something I don't get, why do you have globally
| installed tools that asdf can manage at the same time that you
| have asdf installed?
| robinhoodexe wrote:
| Sounds like nix using devenv[1] also would solve this problem.
|
| [1] https://devenv.sh/
| lexlash wrote:
| Having tried asdf - among other tools - for awhile, dropping it
| for nix+flakes+direnv was great.
|
| Devenv seems nice (in fact it's how I started down this path)
| but I haven't found anything it does for me that I can't get
| out of flakes - so far.
| robinhoodexe wrote:
| I'm considering doing a pilot (~5 devs out of 120) with using
| nix to manage dependencies and build containers at $DAYJOB,
| and here I think devenv is nice as a "one package" plus an
| active community for support.
| lexlash wrote:
| 95% of the difficulty I have at $DAYJOB is nix installation
| and dealing with enterprise certificate/auth crud...sadly
| devenv doesn't help much there.
|
| Our pilot is quite a bit larger. Sticking to plainer flakes
| has made it easier for folks to self-service for now but we
| do intend to re-evaluate devenv.
|
| Same username on twitter if you're interested in chatting.
| dave4420 wrote:
| Yeah... but then you get nix's problems.
|
| - steep steep learning curve, so your team is split between
| those who can understand it and those who have to blindly
| follow checklists and ask for help when something breaks
|
| - it doesn't play well on macOS
| mg74 wrote:
| How doesnt it play well one MacOS? I've been using Nix Home
| Manager + Nix Darwin as my package manager, and Direnv + Nix
| Shell for developer environments; and havent had any problems
| (yet). Is there something I should be aware of?
|
| Agree about the learning curve; but I am going to experience
| onboarding my coworkers onto using Nix only for developer
| environments over the next months; I feel the curve is not
| quite that steep for that limited use case.
| lexlash wrote:
| There's some really annoying edge cases I've found once
| Xcode gets involved and graphical apps are a bit hit and
| miss (Wireshark failed pretty completely for me a few weeks
| back.) I'd still call it a major improvement over the
| alternatives.
|
| Re: onboarding - I'm doing the same thing at a somewhat
| larger scale. Same username on twitter if you want to start
| a support group. :)
| mg74 wrote:
| I'll take you up on that, will follow you on twitter
| (@mg0rn)
| robinhoodexe wrote:
| What exactly are the problems with using it on macOS? So far
| (on my, admittedly, short nix journey), I've not encountered
| any issues that wasn't fixable with 5 mins of google (even as
| a beginner).
| lexlash wrote:
| In my experience, nix-darwin and home manager are a little
| awkward to install together (you'll want both) and central
| management is...tricky. All of these being large company
| problems, mind - I can't rely on the median user googling
| to fix issues, they expect (reasonably) an actively
| supported platform.
|
| I've also had issues with GUIs and Xcode as noted in other
| comments but I don't mind that - those are much more of a
| solved problem than, say, keeping seven different JDKs
| around.
| lexlash wrote:
| That's every solution, honestly - you're just choosing what %
| of users will need help, and frankly asdf has a lot of edges.
| Nix's self-contained declarative stuff is a pain to learn,
| certainly, when used to brew install $whatever - but it's far
| easier to support.
|
| Also it plays really nicely on macOS unless you're trying to
| share nix config across macOS and Linux which...just fork and
| move on, it's not worth it. :)
| jbverschoor wrote:
| I created https://github.com/jrz/container-shell to add a layer
| of security / isolation in addition to tools like asdf.
| codethief wrote:
| Nice, I've been thinking about building something similar.
| However, I'd still like to use my shell configuration/dotfiles
| inside the container (and I'd like my team mates to be able to
| do the same) and, so far, I haven't really found a good
| solution for that.
| king_geedorah wrote:
| I had to install a couple of alternative python versions on my
| dev machine at work and found it was easiest for me to just build
| from source and `make altinstall` with a custom prefix set. From
| there I just always work in virtual environments. This doesn't
| seem to have created any major problems for me, so something like
| asdf doesn't feel necessary. Is there something serious that I've
| missed or is this just a case of different preferred workflows?
| eddyg wrote:
| If you have a requirement for multiple, specific Python
| versions, why not just use pyenv?
|
| https://github.com/pyenv/pyenv
| bmitc wrote:
| > I had to install a couple of alternative python versions on
| my dev machine at work and found it was easiest for me to just
| build from source and `make altinstall` with a custom prefix
| set.
|
| That's basically what asdf does, just automated.
| e12e wrote:
| How do you update the list of installed python versions?
|
| Generally asdf shines when you need more than one system
| installed - say a html or SQL language server that depends on
| node in addition to python for your main app.
| lexlash wrote:
| Having been down this path - asdf didn't go far enough in
| creating reproducible/sealed environments, the quality of the
| plugins per language varied dramatically, shims made a lot of
| assumptions about how tools will be used, and you can expect to
| throw asdf away the moment you need to deploy and then have to
| build something else.
|
| I don't like Nix but I haven't found anything else that scales
| along those critical requirements. I don't think it's a good idea
| to simply replace rbenv/nvm/etc with asdf-ruby-plugin and so on -
| unless your software isn't intended to leave your development
| machine?
|
| (Docker for me fails in the opposite direction - fairly miserable
| to develop with but trivial to deploy.)
| iainmerrick wrote:
| People complain a lot about NPM, but I find it solves all these
| problems reasonably nicely. It's pretty easy to use in
| development and it's easy to deploy (either using node_modules
| in production, or bundling, both approaches work).
|
| Of course it only works if your codebase and tools are all JS-
| based!
|
| Having worked recently on a project that was mostly TypeScript
| with some Python, the TS bits were mostly straightforward but
| the Python was a hassle in both dev and production (I used
| venv). I can see that asdf might have been handy for
| development but if it didn't have a good deployment workflow
| that wouldn't have helped.
| brabel wrote:
| Every language has a tool like NPM (actually, nvm in the
| context of this discussion) these days. The problems tools
| like Nix solves (and arguably, Asdf) is that instead of
| learning each language's tools you only need to learn one
| tool that manages multiple languages and system dependencies.
| e12e wrote:
| > I don't think it's a good idea to simply replace
| rbenv/nvm/etc with asdf-ruby-plugin and so on
|
| ASDF generally doesn't reinvent version management, but wrap
| and re-use ruby-build, node-build etc.
|
| It fails if your single project is a legacy monster needing
| four versions of node, two pythons and a handful of javas - but
| that's not a common use case.
|
| More commonly you have multiple projects, each with a single
| version of node, python and java. For deployment you only need
| one of each - it's in development you need five of each when
| switching between projects.
| karmakaze wrote:
| Out of curiosity, how many dev environments do folks use? Is this
| for reproducible environments shared by members of a team or
| company?
|
| For a single user with one development machine, simply having say
| a time-machine backup could be sufficient. I haven't had
| challenges for personal projects where details mattered. e.g. a
| Maven pom.xml, or Go modules/packages was sufficient for my
| needs.
|
| Historically I'd only cared about automating the spec of
| production environments. Why would I want/need this?
|
| I now recollect once being contacted out of the blue as being a
| person who might be able diagnose/solve an issue at a company I'd
| never worked with. They had two dev machines and only one of them
| could produce a working program. Their team couldn't figure it
| out. I gave them a rate and arrived on-site. It was a Visual
| Basic 6 program, so I just took two half days going through every
| EXE & DLL related to Windows and VB, eventually finding the
| difference. Tedious but not rocket science. Is it to avoid these
| cases?
|
| _Edit: We have project onboarding instructions where I work. I
| suppose it could be useful for making those. I don 't make them
| but could appreciate if they used a standard rather than bespoke
| scheme._
| jdsalaro wrote:
| > Why would I want/need this?
|
| always, golang is overly opinionated regarding where modules
| and binaries are stored. I don't like that and I've blown my
| local development environment into pieces because of that
| (looking at you GRPC, yikes)
|
| But also, imagine that you, like me, need to test Python,
| Java+Kotlin+Gradle and NodeJS+Angular stuff. Do you really want
| to install _all that_ natively ? Just for a couple of merge
| reviews, and even if not, do you _really_ want to install all
| that natively ? The answer is always, IMHO, a resounding and
| clear no.
|
| > It was a Visual Basic 6 program, so I just took two half days
| going through every EXE & DLL related to Windows and VB,
| eventually finding the difference. Tedious but not rocket
| science. Is it to avoid these cases?
|
| For example, but also much worst, as mentioned in the OP it's
| to prevent the very real possibility of crippling your OS's
| language runtimes and also to stay productive.
| brabel wrote:
| IMHO the solution for the problem of devs in the same company
| having different environments is not Adsf and its competitors
| like Mise, but things like Nix/Guix and Docker.
|
| At work, because everyone uses Mac, we ended up using Kandji
| to achieve the same thing: everyone has the same tools and
| environments, but that is only if you already have to use
| that due to security audits and stuff like that.
|
| If I had a small company myself I would probably setup
| everything with Guix as I really like the way it works, more
| than Nix (though only because I prefer Lisp config files and
| because Guix doesn't suffer from any polemics like the flake
| soap opera).
| neonsunset wrote:
| If you had trouble with gRPC and Go combo, you might find the
| way it is integrated in C# a breath of fresh air.
|
| https://learn.microsoft.com/en-
| us/aspnet/core/grpc/basics?vi...
| ufmace wrote:
| I routinely work in Ruby, Python, Javascript, Java, Go, and
| Rust. The thing that drives me to use asdf is that without such
| a tool, every language needs a different version or
| installation manager and they all work slightly differently.
| It's a hassle to remember 6 different sets of commands for how
| to install a new version, check which version is active, switch
| to a different version, and to remember the slightly different
| quirks that each language's tool has. With asdf, they all work
| exactly the same. Granted that with Rust and Go it's usually
| less necessary to keep older versions around, but you
| definitely need it for Python and Ruby. Better to have all the
| languages work the same even if it's a bit more complex than
| needed for some.
| karmakaze wrote:
| Ok, so then it's like a package manager manager. Does it
| update each package manager's lock files too?
|
| Thanks all for the replies. _And sorry if I 'm asking basic
| questions and should just read the asdf readme. On my custom
| layout I have to type A-S-R-H to get asdf._
| RulerOf wrote:
| > Ok, so then it's like a package manager manager.
|
| Still no. asdf manages the versions of the runtimes
| themselves. E.g. I have a project that uses ruby 2.7.2 and
| Terraform 1.1.7. If I'm using asdf, I declare this in the
| .tool-versions file of the project, and then when I
| navigate to that directory, every invocation of `ruby` or
| `terraform` will run those exact versions.
|
| Separately, packages (Ruby Gems, Python packages, etc) will
| also be isolated per-version of each runtime, but that's a
| side effect rather than the goal with asdf.
| lawik wrote:
| I work in about 5-10 versions of Elixir depending on a similar
| number of specific Erlang versions. At any given time. Also 2-3
| NodeJS versions.
|
| It is quite helpful. Also incredibly practical when chevking
| whether Library X will work on an older version.
|
| I do open source and consulting for clients. I deal with a lot
| of projects, my own and other's.
| elzbardico wrote:
| At some time I just decided that having different users is the
| best runtime manager of all.
| neonsunset wrote:
| The existence of asdf is a byproduct of a larger problem: tooling
| for certain popular (Python) and not so popular (Ruby)
| programming languages is simply inadequate.
| Zizizizz wrote:
| Fantastic tool, it also replaces direnv / .env requirements as it
| will automatically load variables you set in your .mise.toml file
| in the [env] section, except that it's much faster than direnv.
| vorticalbox wrote:
| I loved asdf but since moving to immutable fedora I've started
| loving distrobox more.
|
| By giving each box it's own home folder vscode in each has only
| the extensions for that language. E.g I don't have any python
| extensions in my nodejs box.
|
| Been working like this for a couple of weeks now and it's pretty
| good.
|
| If I end up breaking a box I can simply delete it and start over.
| FireInsight wrote:
| Also moved to immutable Fedora, and had to move away from doing
| `pacman -S go python node` on the host for all my dev tools.
| Tried to keep doing that in a distrobox, but it kept breaking
| due to me not updating it. Then I started building my own
| toolbox container with all I need in it for local consumption
| from GHCR, and that works a bit better, but recreating it is
| still annoying. I ended up using Devbox as a Nix wrapper for
| many new projects, but those could all use asdf/mise too, and I
| might consider switching some over.
|
| One project of mine, though, requires a shareable / pseudo-
| reproducible dev environment. Devbox didn't cut it, and mise
| especially couldn't have, since it requires some system deps. I
| went with a Nix Flake, which worked fine, but also started
| building a special distrobox image for the project, this time
| udimg Fedora as a base, as I perceived it as more stable. Using
| it too distrobox still had some issues, but I managed to make a
| shim/helper that runs `pnpm` from inside the container and that
| works pretty perfectly. Might be a bit worse on the performance
| side, though. We'll see.
| victorbjorklund wrote:
| Does people use asdf in prod? Or just on dev machines?
___________________________________________________________________
(page generated 2024-04-28 23:02 UTC)