6 ms·

> 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

> 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.

Waterluvian 8y ago
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.
zengid 8y ago
I don't think it's unheard of though: my employer has their own Nuget package server for internal packages.
- MaulingMonkey 8y ago
  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.
  - iopq 8y ago
    If there is no Internet, I'm going home. You can't seriously expect me to work without StackOverflow
    - MaulingMonkey 8y ago
      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 ;)
    - ben0x539 8y ago
      It's also nice to not have your CI/deploys depend on third-party sites being up.
steveklabnik 8y ago
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.
- ben0x539 8y ago
  Sure, but they have probably on-prem git then anyway, now they need two on-prem things?
Manishearth 8y ago
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.
- ben0x539 8y ago
  "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.
  - eddyb 8y ago
    > 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).
    - Manishearth 8y ago
      "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)
      - ben0x539 8y ago
        Ah, that's cool to hear. Which features of cargo versioning am I missing out on then?

Waterluvian 8y ago

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.

zengid 8y ago

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

MaulingMonkey 8y ago
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.
- iopq 8y ago
  If there is no Internet, I'm going home. You can't seriously expect me to work without StackOverflow
  - MaulingMonkey 8y ago
    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 ;)
  - ben0x539 8y ago
    It's also nice to not have your CI/deploys depend on third-party sites being up.

steveklabnik 8y ago

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.

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

Manishearth 8y ago

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.

ben0x539 8y ago
"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.
- eddyb 8y ago
  > 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).
  - Manishearth 8y ago
    "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)
    - ben0x539 8y ago
      Ah, that's cool to hear. Which features of cargo versioning am I missing out on then?