Ditch Your Version Manager.. to then install a different version manager.
Though it's advocating for a system level version manager, not a language level manager.
Ditch your version manager
11–20 of 155 posts
Re: Ditch your version manager
#12Managing dependencies is a big problem, and I feel like we've given up on solving it directly, and instead built workarounds. If we question our assumptions, the first question is: Why do we need multiple Ruby versions at all? Why isn't the latest version of Ruby sufficient? Well, obviously, Ruby's behavior has changed over time. But why isn't it backward-compatible? Why can't I just run Ruby 3.0 with a flag that tel…
This just adds burden to programming language and library authors. Sure I could almost certainly support Python 2.7 and Python I imagine variations of the above apply to nokogiri and some amount of Ruby core developers.
Re: Ditch your version manager
#13Managing dependencies is a big problem, and I feel like we've given up on solving it directly, and instead built workarounds. If we question our assumptions, the first question is: Why do we need multiple Ruby versions at all? Why isn't the latest version of Ruby sufficient? Well, obviously, Ruby's behavior has changed over time. But why isn't it backward-compatible? Why can't I just run Ruby 3.0 with a flag that tel…
Even if you can somehow convince the major tooling to take that route, you're never going to convince every piece of software to follow suite. It's a problem that must be tackled, there's no side stepping it.
Re: Ditch your version manager
#14Managing dependencies is a big problem, and I feel like we've given up on solving it directly, and instead built workarounds. If we question our assumptions, the first question is: Why do we need multiple Ruby versions at all? Why isn't the latest version of Ruby sufficient? Well, obviously, Ruby's behavior has changed over time. But why isn't it backward-compatible? Why can't I just run Ruby 3.0 with a flag that tel…
Mike has worked hard over the years to have Nokogiri come with its dependencies. It does come with libxml and all that is required.
From https://nokogiri.org
> These dependencies are met by default by Nokogiri's packaged versions of the libxml2 and libxslt source code, but a configuration option --use-system-libraries is provided to allow specification of alternative library locations.
Some authors work hard to have their tools do the right thing and consistently.
Re: Ditch your version manager
#15Re: Ditch your version manager
#16Re: Ditch your version manager
#17> Nix is a tool that takes a unique approach to package management and system configuration.
Nix is the basis of an OS distro: NixOS.
This article is just re-articulating the idea that {the/an} OS distro should be managing this stuff, and not some fledgling language-specific programs (that go behind its back, and do a half-baked job by not controlling the packages external to their language ghetto).
Re: Ditch your version manager
#18woah this direnv thing is neat
Re: Ditch your version manager
#19Does this work on Windows? For me, the version manager that provides the nicest experience cross-platform is Cargo from Rust. It can specify and pin specific versions. It is super easy to give to a fellow developer and have them reproduce the build. In addition, because Rust is suitable for low-level, high performance work, many times all the libraries you actually need are written in Rust and everything works very s…
Nix is very unixy so it probably could be made to work on WSL, but not native windows. Yes, if all of your dependencies are written in a single language, you can use the language-specific version manager. TFA was pointing out a solution that work across different languages.
It would be very nice to have a cross language and cross platform package manager.
Most single language package managers are cross platform, and many single platform managers are cross language.
Re: Ditch your version manager
#20Nix, guix and traditional package managers that support multiple versions (like dnf) are better solutions than just containerizing the whole thing.
But here we are, some projects only give development instructions based on containers, others support only container based deployment. You need to go out of the way trying to convert dockerfiles into regular install/setup instructions.
Containers are great and all, they solve many problems but they're not the only solution and theyre definitely not the best solution to every problem.