4 ms·

>these people need [their package manager] and [their source code management tool] to deploy? Seriously? Not really sure I understand what you're implying ther

>these people need [their package manager] and [their source code management tool] to deploy? Seriously? Not really sure I understand what you're implying there

rabidrat 9y ago
A public package manager and a public source code management tool, both of which are outside of your control. You should be able to deploy from a local [verified and audited] cache of your dependencies.
- zbentley 9y ago
  That's a good goal to strive for, but isn't necessary or practical for everyone. Maintaining local/hosted artifact caches, verifying them, and auditing them is a big hassle, and unless you make something (e.g. fintech, healthtech) that might need such an audit or emergency release, might not be worth the trouble. Itty bitty company making a social website on a shoestring budget/runway with very few developers? Might just be worth postponing a release a day or two if NPM or GitHub are having issues.
  - not_kurt_godel 9y ago
    virtualenv makes it trivial. It's not like it's strictly enterprise-grade tech.
    - zbentley 9y ago
      How does vrtualenv make maintaining, auditing, and using a local mirror of dependencies trivial? Seems to me I can download a poisoned package into a venv cache just as easily as I can download it with wget, and unless I take the time to check, I’m none the wiser either way.
      - not_kurt_godel 9y ago
        I was referring specifically to not being able to deploy due to a package manager being down. Of course there are still issues that can crop up with using virtualenv.
hoistbypetard 9y ago
I'm not the poster you're replying to, but I think I understand it. npm is not just their package management tool... the way most people use it, it depends on someone else's package registry/repository to deploy to your own servers. And github is someone else's source code management tool/server. As a matter of policy, if I can't have something on my own server (or one my org controls) I don't get to rely on it to deploy/run my application. So I think I get the parent's comment... it's a really foreign situation, to me, to depend on the availability of stuff like this on servers I (or my org) don't control in order to deploy my application. I'm sure the people who depend on these things look at me and say "Wait. You have to set up your own package repository and source control before you can deploy instead of using all this nice stuff that's available in the cloud? Seriously?"
- christophilus 9y ago
  Yeah. I've been on both sides of this coin. If I'm deploying cloud software (which I am, these days), then I have no problem relying on cloud software to make that deployment smoother. But if I ever go back to writing native applications, I sure as hell won't be reliant on the internet in order to manage intranet deployments. These are two different paradigms, and what works well in one doesn't make any sense in the other.
hyperpape 9y ago
I haven’t dug too much, but I believe at my work, we run a server that hosts all our jars, and is the source of truth for all our builds. Nothing that’s been checked in goes straight to the Internet (you can add new dependencies to uncommitted code). And we’re only ~30 devs.

>these people need [their package manager] and [their source code management tool] to deploy? Seriously? Not really sure I understand what you're implying there

rabidrat 9y ago

A public package manager and a public source code management tool, both of which are outside of your control. You should be able to deploy from a local [verified and audited] cache of your dependencies.

zbentley 9y ago
That's a good goal to strive for, but isn't necessary or practical for everyone. Maintaining local/hosted artifact caches, verifying them, and auditing them is a big hassle, and unless you make something (e.g. fintech, healthtech) that might need such an audit or emergency release, might not be worth the trouble. Itty bitty company making a social website on a shoestring budget/runway with very few developers? Might just be worth postponing a release a day or two if NPM or GitHub are having issues.
- not_kurt_godel 9y ago
  virtualenv makes it trivial. It's not like it's strictly enterprise-grade tech.
  - zbentley 9y ago
    How does vrtualenv make maintaining, auditing, and using a local mirror of dependencies trivial? Seems to me I can download a poisoned package into a venv cache just as easily as I can download it with wget, and unless I take the time to check, I’m none the wiser either way.
    - not_kurt_godel 9y ago
      I was referring specifically to not being able to deploy due to a package manager being down. Of course there are still issues that can crop up with using virtualenv.

hoistbypetard 9y ago

I'm not the poster you're replying to, but I think I understand it. npm is not just their package management tool... the way most people use it, it depends on someone else's package registry/repository to deploy to your own servers. And github is someone else's source code management tool/server. As a matter of policy, if I can't have something on my own server (or one my org controls) I don't get to rely on it to deploy/run my application. So I think I get the parent's comment... it's a really foreign situation, to me, to depend on the availability of stuff like this on servers I (or my org) don't control in order to deploy my application. I'm sure the people who depend on these things look at me and say "Wait. You have to set up your own package repository and source control before you can deploy instead of using all this nice stuff that's available in the cloud? Seriously?"

christophilus 9y ago
Yeah. I've been on both sides of this coin. If I'm deploying cloud software (which I am, these days), then I have no problem relying on cloud software to make that deployment smoother. But if I ever go back to writing native applications, I sure as hell won't be reliant on the internet in order to manage intranet deployments. These are two different paradigms, and what works well in one doesn't make any sense in the other.

hyperpape 9y ago

I haven’t dug too much, but I believe at my work, we run a server that hosts all our jars, and is the source of truth for all our builds. Nothing that’s been checked in goes straight to the Internet (you can add new dependencies to uncommitted code). And we’re only ~30 devs.