Hacker News Reader

Comment by joaodlf | Hacker News Reader

Commit hashes seem to be the way to go, for sure, at least to be safe. I really don't want to put our vendor content in the repos.

It's just a tad absurd when you're used to mature package managers in other languages.

View on HN

Honestly, most package managers just bring their own problems. I'd rather commit source code than troubleshoot npm, pip, nix, maven, etc errors all day long. The only package manager I've found that works reliably has been Cargo (Rust).

There has been a lot of talking between the committee that created `dep` and folks who've implemented other systems, including Cargo. I have high hopes.

indeed, we've talked with them quite a bit :)

I don't think I've ever had a problem with Bundler.

Me neither. In fact, I rarely have trouble with package managers. They're amazing.

I envy you. I use Nix, pip, and npm on a daily basis and it's an uphill battle. I haven't used Bundler.

Well, nix looks awfully complicated. I've had trouble deploying applications using pip. Npm hasn't given me any trouble.

Bundler is lovely.

Once I did 'sudo npm -g update npm', just 3.x to 3.x+1 and the hell broke loose. I had to wipe entire nodejs and reinstall from scratch.

In other cases, 'npm update <package>' doesn't work and I have to do uninstall/install. Very common with typescript, for example.

i would be a happy man if every package manager for any language has magically become cargo overnight.

Until cargo starts to support binary crates across projects I would be a very unhappy man.

I have better things to do with my time than watching the same crates being compiled multiple times.

Well go builds so fast you wouldn't be waiting.

It is still slower than Turbo Pascal (MS-DOS). :)

In any case, I appreciate that Go at least supports binary packages, but Go isn't a language for me, given the type system decisions.

I believe the current intended use is a human-editable "manifest file" where you specify desires/intent, preferably semver, ideally only as necessary, and a machine-generated "lock file" which specifies the actual hash of every transitive dependency, so builds are fully specified and reproducible.

But they all have to vendor as well if they want reliable builds. Otherwise you end up with everything breaking when a developer decides to do a forced push or take his repo off github.

Not if there is a central repository which doesn't allow removal of packages.

Well, you can vendor, or you can have an internal mirror/cache of repositories.

Force pushes - by far more common than straight-up repository removal - are handled without problem; we let you stick with your old version. (At least, that's how it should be - there might be a couple more test cases to write. I know I designed for this problem early on).

Repo removal, renaming, or whatever, are still problems, for sure.

Today, dep populates vendor/ with dependencies, and works equally well whether you decide to commit them or not.

Reply on news.ycombinator.com