4 ms·

Why would you ask panamax to mirror everything though? You are maintaining a manifest of all your organizations dependencies right? Why would I mirror ancient

Why would you ask panamax to mirror everything though? You are maintaining a manifest of all your organizations dependencies right? Why would I mirror ancient versionsbof clap and that crate that checks your aol mail? Also, nexus doesn't have a functioning cargo plugin, it is community made and stagnant. Artifactory does support it. And I'm guessing artifactory is what most people are using for a private registry too given the state of the others.

wongarsu 3y ago
Mirroring everything gives me the ability to not just build existing software independently of crates.io outages or decisions, but also to not be impacted in software development by such incidents. To me development involves using packages or package versions I might not have used before. Of course if your development is already set up in a way that prevents you from easily adding, experimenting with or updating dependencies, maybe because of how the vetting process works, that might not be an issue for you. And many places are completely fine with just being able to build
- galangalalgol 3y ago
  Yeah, that makes sense and we should probably expand a bit. I can't imagine wanting versions that are older than anything we support or what those things bring in. Also we prune stuff that gets unmaintained or has a cve pop up. And we don't mess with copyleft, not against it, but when everything is statically linked you get into incompatible combinations quickly.
- devman0 3y ago
  Having worked in enterprise software, it has been my experience that the majority of in-house repos operate in a caching mode and not mirroring. The critical element is being able to build things in CI that are being PR'd/reviewed or are already merged and in both cases the relevant dependencies should already be cached. That and being able to re-build any tagged releases, again should be cached. New libraries being temporarily unavailable are generally not going to hold up critical processes, and the upstreams have been available enough for that to never be a serious issue.
  - jamesfinlayson 3y ago
    Agreed - I can't remember what was used at my last job but you submitted a package to be mirrored and then each night it pulled in any new releases.
- andrewaylett 3y ago
  I'm quite happy -- even in commercial development -- to not be able to download new things if the package source is down. But not being able to access my existing dependencies is a blocker: I must be able to redeploy my own stuff, and to make fixes that don't involve version bumps. It's unlikely that I'll need a new dependency at the exact moment that the source is down, but fairly likely that if the source is down then I'll want to build something. For personal projects I'll have stuff cached locally, and I don't mind so much if I need to wait for CI. For work stuff I need to be able to fetch my dependencies in CI. Also, hammering upstream with requests for every single build is both slow and also sort of rude.

wongarsu 3y ago

Mirroring everything gives me the ability to not just build existing software independently of crates.io outages or decisions, but also to not be impacted in software development by such incidents. To me development involves using packages or package versions I might not have used before. Of course if your development is already set up in a way that prevents you from easily adding, experimenting with or updating dependencies, maybe because of how the vetting process works, that might not be an issue for you. And many places are completely fine with just being able to build

galangalalgol 3y ago
Yeah, that makes sense and we should probably expand a bit. I can't imagine wanting versions that are older than anything we support or what those things bring in. Also we prune stuff that gets unmaintained or has a cve pop up. And we don't mess with copyleft, not against it, but when everything is statically linked you get into incompatible combinations quickly.
devman0 3y ago
Having worked in enterprise software, it has been my experience that the majority of in-house repos operate in a caching mode and not mirroring. The critical element is being able to build things in CI that are being PR'd/reviewed or are already merged and in both cases the relevant dependencies should already be cached. That and being able to re-build any tagged releases, again should be cached. New libraries being temporarily unavailable are generally not going to hold up critical processes, and the upstreams have been available enough for that to never be a serious issue.
- jamesfinlayson 3y ago
  Agreed - I can't remember what was used at my last job but you submitted a package to be mirrored and then each night it pulled in any new releases.
andrewaylett 3y ago
I'm quite happy -- even in commercial development -- to not be able to download new things if the package source is down. But not being able to access my existing dependencies is a blocker: I must be able to redeploy my own stuff, and to make fixes that don't involve version bumps. It's unlikely that I'll need a new dependency at the exact moment that the source is down, but fairly likely that if the source is down then I'll want to build something. For personal projects I'll have stuff cached locally, and I don't mind so much if I need to wait for CI. For work stuff I need to be able to fetch my dependencies in CI. Also, hammering upstream with requests for every single build is both slow and also sort of rude.