3 ms·

huh? so like, don't use open source libraries?

by timwis 9y ago

dozzie 9y ago
Are you implying that you cannot use others' code unless you download it from random places from the internets? That the others' code is fundamentally different from your code and thus cannot be hosted from your own repository?
jasonlotito 9y ago
That's not what the OP is trying to say, though they have a hard time coming out and saying it, and their reply to you doesn't help matters. Instead, what they are saying is that you should 1) use a specific version, and 2) host that version in a location you control. This way, updates don't impact your build just because you clamp to the latest (which is a moving target). Also, if they happen to rerelease a tag which worked for a previous build you made and now doesn't, you are still pulling in the same thing. Basically, if you depend on something, host it yourself. Otherwise, you are asking to be bit by this.
- derefr 9y ago
  > host that version in a location you control I don’t see how this is implied or required by what the GP said. Lockfiles exist; docker-image and OS package hash-refs exist. Heck, nix exists. Getting what you expected to get is a solved problem, and does not require “host[ing] it yourself.” Now, availability of your deployment might require hosting it yourself. (Though more often your availability figures will be far worse than those of Docker Hub or launchpad.net.)
  - nucleardog 9y ago
    I mean, up until last year someone could permanently depublish entire packages from certain package managers without restriction. No amount of hash-refs are going to ensure you have the right package if it just doesn't exist anymore. I think availability is exactly what dozzie was getting at by specifying 'production'. You want your production systems to be robust, not reliable at the whims of half a dozen different ecosystems all with different policies, procedures, humans, support agreements, etc. (This is without even touching on infrastructure availability.)

huh? so like, don't use open source libraries?

by timwis 9y ago

huh? so like, don't use open source libraries?

Are you implying that you cannot use others' code unless you download it from random places from the internets? That the others' code is fundamentally different from your code and thus cannot be hosted from your own repository?

jasonlotito 9y ago

That's not what the OP is trying to say, though they have a hard time coming out and saying it, and their reply to you doesn't help matters. Instead, what they are saying is that you should 1) use a specific version, and 2) host that version in a location you control. This way, updates don't impact your build just because you clamp to the latest (which is a moving target). Also, if they happen to rerelease a tag which worked for a previous build you made and now doesn't, you are still pulling in the same thing. Basically, if you depend on something, host it yourself. Otherwise, you are asking to be bit by this.

derefr 9y ago
> host that version in a location you control I don’t see how this is implied or required by what the GP said. Lockfiles exist; docker-image and OS package hash-refs exist. Heck, nix exists. Getting what you expected to get is a solved problem, and does not require “host[ing] it yourself.” Now, availability of your deployment might require hosting it yourself. (Though more often your availability figures will be far worse than those of Docker Hub or launchpad.net.)
- nucleardog 9y ago
  I mean, up until last year someone could permanently depublish entire packages from certain package managers without restriction. No amount of hash-refs are going to ensure you have the right package if it just doesn't exist anymore. I think availability is exactly what dozzie was getting at by specifying 'production'. You want your production systems to be robust, not reliable at the whims of half a dozen different ecosystems all with different policies, procedures, humans, support agreements, etc. (This is without even touching on infrastructure availability.)