Hacker News Reader

Comment by ben0x539 | Hacker News Reader

> People maintaining proprietary/closed-source code cannot use crates.io, and instead are forced to use git or path dependencies. This is usually fine for small projects, but if you have a lot of closed-source crates within a large organization, you lose the benefit of the versioning support that crates.io has.

I'm surprised that making people run their own registries is the preferred way to address this, instead of implementing versioning support for git dependencies.

There's many bad things I say about golang, but "I wish this module system additionally required me to host a language-specific package repository" is not one of them.

View on HN

I dunno. The worst part of Go in my opinion is that disaster that is packaging. I like rust because there isn't eleventy ways to do things like that. I can certainly see your perspective. I'm just of the other opinion.

What do you mean by "versioning support for git dependencies"? We do support pulling in git dependencies based on a branch (I think tags work?)

We also support checking the version of the git dep.

It's fetching the dep that's the problem. Git has no uniform protocol for talking about versions, especially when it comes to resolving SemVer ("you asked for 0.2.1 but I also have 0.2.5, here you go")

If you want go-style import resolution use a local git dep. That works fine. It's specifically when you want all the features of cargo's version resolution -- which git doesn't understand -- you need to use a custom registry.

"Versioning support" is the wording from the release notes. I don't know why cargo's version resolution logic can't be applied to git dependencies, treating a tag like "v4.2" or "4.2" as a version 4.2 doesn't seem very contentious. I also don't know what you mean by local git dep.

> I also don't know what you mean by local git dep.

Presumably, the `git` URL for dependencies, in `Cargo.toml`, can point to a local git repository. That should let you refer to a branch / commit of that repository, other than the one currently checked out (which is what using a `path` dependency would give you).

"local git dep" was a mistake, I meant "git dep", which can be used in a way that approximates Go's import system if you use versioned tags.

(The "local" comes from it being in-house but that's confusing)

Ah, that's cool to hear. Which features of cargo versioning am I missing out on then?

Actual semver based version resolution.

And yes, this _can_ be added with some ad hoc scheme that requires you to use a certain kind of git tag, but that's not what people are asking for.

There’s a ton of people who want a variety of solutions for a ton of things; many people require on-prem for this kind of thing. We’re building out a variety of solutions, this one happened to land first.

Sure, but they have probably on-prem git then anyway, now they need two on-prem things?

I don't think it's unheard of though: my employer has their own Nuget package server for internal packages.

It can be useful to run your own package server even if you're not creating your own packages. You can use this to keep a curated list of packages that your team finds commonly useful / has audited / has had the license blessed by legal / ???, or to be productive during an internet outage, slowdown, or lockdown, etc.

If there is no Internet, I'm going home. You can't seriously expect me to work without StackOverflow

It's also nice to not have your CI/deploys depend on third-party sites being up.

There's plenty I can work on without SO - that large backlog of things to document, for example. And just because your dev machines are on a locked down network doesn't mean you have no internet.

If perforce is down, however, I'm starting a riot ;)

Reply on news.ycombinator.com