TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ditch your version manager

167 点作者 Arkh4m超过 3 年前

25 条评论

throwaway984393超过 3 年前
First, you want a &quot;dependency manager&quot;. That&#x27;s not what Nix is, clearly. Nix is a package manager.<p>Second, to use this package manager, you first need to install <i>direnv</i>. How do you install it? with <i>brew</i>, a different package manager.<p>Third, you have to learn a new functional programming language. Right. Because normally to put together a toolbox, I often learn to speak a few phrases in Swahili first.<p>Fourth, finally, we get to install a simple Unix program, that any package manager could have provided.<p>For the fifth trick, freezing dependencies, you first have to have all the correct versions of all the dependencies to do what you want. How do you establish the right ones? Manually. Just like with any other package manager that builds apps against a specific tree of build deps. &quot;Reproducibility!&quot; Because no other package manager could possibly download the same tarballs and run the same commands. Must be all that functional programming magic.<p>And sixth, the idea that this will work forever. Right. Because any other distro and package manager could not possibly work again in the future, with a mirror of all the packages in a release. That&#x27;s only for super cool futuristic package managers. No way to reproduce the same packages in the future with old package managers.<p>Look, Nixians, this is all old hat. Every decent package manager can do all these things, just in a less complicated way. Modern systems use containers, and they don&#x27;t need Nix for that. Nix is basically just the new Gentoo: a distro for hobbyists who tell themselves they&#x27;re advanced while all the professionals use something else.
评论 #28591414 未加载
评论 #28591960 未加载
评论 #28592090 未加载
评论 #28591176 未加载
评论 #28591504 未加载
评论 #28591495 未加载
KronisLV超过 3 年前
&gt; My ideal dependency manager would allow me to specify each and every dependency that is required to work on my projects. It should be easily reproducible, declarative and easy to upgrade.<p>To me it feels like what&#x27;s left out here is the fact that you need the amount of dependencies that you have to be reasonable in the first place, otherwise no single piece of software is going to help you all that much.<p>For example, a new project that was created with &quot;create-react-app&quot; takes 181 MB of space on disk and has 35&#x27;894 files in it. That includes about 1467 modules, all for a relatively simple web application. It doesn&#x27;t matter if you&#x27;re using package.json&#x2F;package.lock, or any other tool or solution out there - with that amount of dependencies you&#x27;re simply not doing dependency &quot;management&quot; of any kind.<p>I&#x27;d argue that if you have &gt;100 dependencies in your project, it&#x27;s probably too big, unless you have a team that&#x27;s dedicated to managing and auditing all of them. Of course, no one actually audits their dependencies when faced with such large numbers, and so what&#x27;s left for most developers is to just trust what&#x27;s out there.
评论 #28590818 未加载
评论 #28591450 未加载
IceWreck超过 3 年前
Nix, guix and traditional package managers that support multiple versions (like dnf) are better solutions than just containerizing the whole thing.<p>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&#x2F;setup instructions.<p>Containers are great and all, they solve many problems but they&#x27;re not the only solution and theyre definitely not the best solution to every problem.
评论 #28590538 未加载
评论 #28591006 未加载
评论 #28590517 未加载
评论 #28591071 未加载
评论 #28590830 未加载
oneplane超过 3 年前
Ditch Your Version Manager.. to then install a different version manager.
评论 #28590146 未加载
评论 #28589983 未加载
jeffparsons超过 3 年前
Arrived expecting to vehemently disagree, given how much I rely on version managers for everything (Ruby, Node, etc.) in my work. Came away thinking, yeah, okay, Nix probably is a better solution to all of this and more.
phendrenad2超过 3 年前
Managing dependencies is a big problem, and I feel like we&#x27;ve given up on solving it directly, and instead built workarounds.<p>If we question our assumptions, the first question is: Why do we need multiple Ruby versions at all? Why isn&#x27;t the latest version of Ruby sufficient? Well, obviously, Ruby&#x27;s behavior has changed over time. But why isn&#x27;t it backward-compatible? Why can&#x27;t I just run Ruby 3.0 with a flag that tells it to emulate Ruby 2.6? Or 1.8 for that matter?<p>Okay another one. &quot;Nokogiri&quot; is the Ruby gem (library) for parsing XML (including HTML). You always need to remember to install libxml when you install it. Why? Why doesn&#x27;t Nokogiri include an XML parser? Because it would be slow? You can include a native binary in the gem which does the hard computations. Will that work on random new architectures like M1? No? But you can fall back to a Ruby implementation and show a warning message. Also, what if I just need some quick XML parsing and don&#x27;t care if the parsing is 1000x slower? Can I just get Nokogiri with the Ruby-implemented parser? No? Why not?<p>Then every single Ruby gem out there starts using newer Ruby features and thus, you must update your Ruby version. Why can&#x27;t library authors gracefully handle older versions of Ruby?
评论 #28590148 未加载
评论 #28590218 未加载
评论 #28590904 未加载
评论 #28590204 未加载
评论 #28590145 未加载
评论 #28590865 未加载
评论 #28591434 未加载
评论 #28590882 未加载
zaSmilingIdiot超过 3 年前
Looks interesting enough... But how does one solve the issue of security level updates for some dependency language? Or when a particular version of some application reaches EOL and is no longer maintained, or theres some functionality in a newer version of Nodejs|Ruby|etc thats needed?<p>From what I understand this would require an update to the Nix version that supports it... but that also potentially means bumping other environmental versions as well, which might not be desired. But I suppose this would amount to the user arranging the structure of their filesystem correctly so its one &quot;system&quot; per dir&#x2F;folder... Or is there a better way to cater to this? And I suppose this still means that the node modules, gems, etc that are being used then anyway also need to be updated after this accordingly.<p>From my limited understanding of Nix, it seems interesting, and the article was actually useful to me. But I cant seem to shake the feeling that this is another packaging abstraction like others before it, and while it seems like a better variant, its not much different to having X, Y and Z listed as requirements and then letting the dev go off and install such dependencies on their system, in the way that they best know how. Juniors or those new to a specific environment might not know the ecosystem so well so as to know to use rbenv or nvm or whatever, but I&#x27;m not sure how Nix solves this issue differently than one of the specific tools its replacing.<p>Theres clearly more to Nix than just setting up language environments, which I&#x27;m guessing is where its usefuleness really kicks in. But purely for lang env set up, I&#x27;m not sure I see a point over other tooling...
评论 #28591589 未加载
评论 #28591768 未加载
kazinator超过 3 年前
&gt; <i>Nix is a tool that takes a unique approach to package management and system configuration.</i><p>Nix is the basis of an OS distro: NixOS.<p>This article is just re-articulating the idea that {the&#x2F;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).
评论 #28590438 未加载
评论 #28590659 未加载
RcouF1uZ4gsC超过 3 年前
Does this work on Windows?<p>For me, the version manager that provides the nicest experience cross-platform is Cargo from Rust.<p>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 seemlessly (for example, there is no need to have libxml like the Ruby xml library needed, because you can probably write an XML parser in Rust that will be on par or better performance wise with libxml).
评论 #28590047 未加载
dmitriid超过 3 年前
The more I see posts praising nix, the more I am confused by the decisions made.<p>In this post:<p>--- start quote ---<p>How about a different version of Ruby or Node? Let’s say that our project depends on Ruby 2.6 and Node 10. We can go and search for those specific versions<p>--- end quote ---<p>So, to begin with, we still need a &quot;version manager&quot;, because we want specific package versions. But look at how this is implemented in nix:<p><pre><code> let pkgs = import &lt;nixpkgs&gt; { }; in pkgs.mkShell { buildInputs = [ pkgs.hello pkgs.ruby_2_6 pkgs.nodejs-10_x ]; } </code></pre> Why? Because unlike every sane package&#x2F;dependency manager where you specify a package and a version, nix pretends each version is a separate package.<p>And these packages aren&#x27;t even correct. If you do go and search for ruby, for example [1], you get the following:<p><pre><code> ruby Version: 2.7.4 ruby_3_0 Version: 3.0.2 ruby_2_6 Version: 2.6.8 </code></pre> This... This is laughable. How do I install ruby 2.6.8? Oh, there&#x27;s no ruby_2_6_8, because of course there isn&#x27;t. And this could be difference between a secure system and all your base are belong to us.<p>And they call this reproducible builds?<p>And that&#x27;s before getting into the ridiculous<p>--- start quote ---<p>All the software that we installed depends on the specific version of the nixpkgs channel that we installed on our system [whose only version is a commit hash in a git repo]<p>--- end quote ---<p>So you need an extra tool [2] for, quote, &quot;painless dependencies for Nix projects.&quot;<p>Yes, sure. I&#x27;m definitely ditching my version managers in favor of this tool, that hasn&#x27;t solved these issues <i>in 18 years of its existence</i>.<p>[1] <a href="https:&#x2F;&#x2F;search.nixos.org&#x2F;packages?channel=21.05&amp;from=0&amp;size=50&amp;sort=relevance&amp;type=packages&amp;query=ruby" rel="nofollow">https:&#x2F;&#x2F;search.nixos.org&#x2F;packages?channel=21.05&amp;from=0&amp;size=...</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;nmattia&#x2F;niv" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nmattia&#x2F;niv</a>
评论 #28592052 未加载
gizdan超过 3 年前
As an alternative, I use asdf[0] which is written in bash. It allows you to manage versions of any package through plugins. Plugins can be written in any language (as long as they can be set to chmod +x). Most plugins are written in bash.<p>Though there is a wealth of plugins, what&#x27;s nice is that it&#x27;s trivial to write your plugin. So if something doesn&#x27;t exist yet, or you have some internal tool you need to version, it takes less than an hour to write a plugin.<p>[0] <a href="https:&#x2F;&#x2F;asdf-vm.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;asdf-vm.com&#x2F;</a>
type0超过 3 年前
Nice introduction to nix and niv!
ricardobeat超过 3 年前
I had the feeling this would be an ad for Nix after reading the first few paragraphs.<p>Is there really a difference from the Docker example given (“your Ubuntu version is EOL”) though? Any of your language or tools can be EOL’ed even if installed via nix, and you have the exact same problem in your hands.
评论 #28596239 未加载
mongol超过 3 年前
Everything to install with Nix must be packaged &quot;the Nix way&quot;, I assume? How is the breadth and quality of Nix packages? Just for fun I checked the kiwi image builder, from the openSUSE project, which I recently had some versioning problems with, and it was not there.
评论 #28591522 未加载
shtps超过 3 年前
The problem I have with Nix (and Guix) is that you&#x27;re shit out of luck if you need it to work together with some network based package manager or existing project that someone didn&#x27;t add to it yet.<p>It gets really complicated really fast, and things that &quot;just work&quot; with other packages managers and projects, because they are opinionated and linux-y, most of the time don&#x27;t work well with Nix or have to be shoehorned into it.<p>It always feels like you&#x27;re fighting against everything to get things into Nix that just weren&#x27;t meant to be.
评论 #28594766 未加载
Kiro超过 3 年前
&gt; My ideal dependency manager would allow me to specify each and every dependency<p>Don&#x27;t you do that in Docker? I&#x27;ve read the sentence about Ubuntu EOL but don&#x27;t really understand.
marcus_holmes超过 3 年前
Now can we solve the problem of installing a program by curl&#x27;ing a script from the internet to shell? (bonus points for requiring sudo too)
评论 #28600482 未加载
yewenjie超过 3 年前
Nix Flakes are easier to manage than niv though.
评论 #28590891 未加载
hda111超过 3 年前
Good introduction to Nix. I wish I would have had this when I started.<p>But what do they mean with “works forever”? What if the Git repo or Web server of the project is gone in several years? How do you reproduce it? Does niv include a local source code mirror?
评论 #28593247 未加载
blt超过 3 年前
This seems like a good thing for system-level packages, but what about those language-level packages? Could Nix replace both dockerfiles (or a list of apt packages) and pip&#x2F;conda?
评论 #28591066 未加载
thehm超过 3 年前
Looks interesting, but I don&#x27;t see any benefits over using conda. And given the network effect benefit, conda seems like it will remain the more useful tool.
jbergens超过 3 年前
I think webassembly may be a solution to many of the problems with installing tools. We would need an npm like manager for all the tools&#x2F;libs.
评论 #28593583 未加载
a-dub超过 3 年前
woah this direnv thing is neat
评论 #28591352 未加载
kiryin超过 3 年前
In my experience, Nix and Guix are nice toys, but I&#x27;m just not ready for the kind of lifestyle change they require to actually use them for anything. For me, &quot;pinning&quot; a package to a specific version means not downloading and building a newer version.
评论 #28591296 未加载
coldtea超过 3 年前
Oh, an Amway-style pitch for Nix.