5 ms·

Honest question: have you ever worked as an application developer? Responsible for getting working artifacts to users as a means to an end? Pinning dependencie

Honest question: have you ever worked as an application developer? Responsible for getting working artifacts to users as a means to an end? Pinning dependencies absolutely and unquestionably works better, and for longer, than dynamic linking, for this use case.

tgbugs 6y ago
If developers are unwilling to maintain dependencies and be good citizens of the larger language community, should they be adding those dependencies in the first place? If you're not operating in the large ecosystem then fine. But if your project is on e.g. pypi, then there is an issue. (edit: Note, yes I know the virtualenvs exist, docker exists, etc. but those are space and complexity trade-offs made as a workaround for bad development practices)
AshamedCaptain 6y ago
Perhaps I still fail to explain myself: what I am saying is that _not pinning_ only _adds_ more choices, so by definition it can only work better. Pinned or not, if a software update breaks things, you can always just revert back to a previous version of your dependencies. This applies to a myriad soft problems including a dependency changing interface. However, when pinning, when one of your static dependencies is broken due to a change outside your control (e.g. hardware, operating system, security issue making it unusable, or something else), the user's only recourse is to call the developer to fix the software. I am not claiming whether one happens more frequently than the other, or claiming that hardware changes cannot break the main software itself, which often nullify the point. All these issues can happen to both software with static linking or dynamic linking. However dynamic linking has at least one extra advantage that static linking cannot have, and the opposite is not true. > have you ever worked as an application developer? Responsible for getting working artifacts to users as a means to an end? Look, ironically I find that all of this crap discussion is because of a newer generation of "application developers" that do not know yet what does it mean to "deliver working artifacts to users". Imagine my answer to that question.
- sagichmal 6y ago
  > However, when pinning, when one of your static dependencies is broken due to a change outside your control (e.g. hardware, operating system, security issue making it unusable, or something else), the user's only recourse is to call the developer to fix the software. In practice, this happens so infrequently it can be ignored as a risk. (When it does happen, users generally don't expect the software to continue to work.) > dynamic linking has at least one extra advantage... You don't seem to be acknowledging the downside risk to dynamic linking which motivates the discussion in the first place. An update to a dynamically linked dependency which breaks my delivered artifact is an extremely common event in practice.
  - AshamedCaptain 6y ago
    > In practice, this happens so infrequently it can be ignored as a risk. Well I disagree there. Security issues or external protocol changes (e.g. TLSv1.2 to TLSv1.3) are rather frequent, not to mention usually customer wants to upgrade their machines (old ones broke) and existing operating system no longer supports the new hardware. > An update to a dynamically linked dependency which breaks my delivered artifact is an extremely common event in practice. Again, I agree. A "surreptitious" dependency update breaking the software is much more common. However, I have already acknowledged that _two times already_, and the point that I'm making is that it doesn't matter if you are pinning dependencies or not: customer CAN FIX these issues without help from the developer. They just have to roll back the update! On the other hand customer CAN'T fix the first issue (e.g. new hardware).

tgbugs 6y ago

If developers are unwilling to maintain dependencies and be good citizens of the larger language community, should they be adding those dependencies in the first place? If you're not operating in the large ecosystem then fine. But if your project is on e.g. pypi, then there is an issue. (edit: Note, yes I know the virtualenvs exist, docker exists, etc. but those are space and complexity trade-offs made as a workaround for bad development practices)

AshamedCaptain 6y ago

Perhaps I still fail to explain myself: what I am saying is that _not pinning_ only _adds_ more choices, so by definition it can only work better. Pinned or not, if a software update breaks things, you can always just revert back to a previous version of your dependencies. This applies to a myriad soft problems including a dependency changing interface. However, when pinning, when one of your static dependencies is broken due to a change outside your control (e.g. hardware, operating system, security issue making it unusable, or something else), the user's only recourse is to call the developer to fix the software. I am not claiming whether one happens more frequently than the other, or claiming that hardware changes cannot break the main software itself, which often nullify the point. All these issues can happen to both software with static linking or dynamic linking. However dynamic linking has at least one extra advantage that static linking cannot have, and the opposite is not true. > have you ever worked as an application developer? Responsible for getting working artifacts to users as a means to an end? Look, ironically I find that all of this crap discussion is because of a newer generation of "application developers" that do not know yet what does it mean to "deliver working artifacts to users". Imagine my answer to that question.

sagichmal 6y ago
> However, when pinning, when one of your static dependencies is broken due to a change outside your control (e.g. hardware, operating system, security issue making it unusable, or something else), the user's only recourse is to call the developer to fix the software. In practice, this happens so infrequently it can be ignored as a risk. (When it does happen, users generally don't expect the software to continue to work.) > dynamic linking has at least one extra advantage... You don't seem to be acknowledging the downside risk to dynamic linking which motivates the discussion in the first place. An update to a dynamically linked dependency which breaks my delivered artifact is an extremely common event in practice.
- AshamedCaptain 6y ago
  > In practice, this happens so infrequently it can be ignored as a risk. Well I disagree there. Security issues or external protocol changes (e.g. TLSv1.2 to TLSv1.3) are rather frequent, not to mention usually customer wants to upgrade their machines (old ones broke) and existing operating system no longer supports the new hardware. > An update to a dynamically linked dependency which breaks my delivered artifact is an extremely common event in practice. Again, I agree. A "surreptitious" dependency update breaking the software is much more common. However, I have already acknowledged that _two times already_, and the point that I'm making is that it doesn't matter if you are pinning dependencies or not: customer CAN FIX these issues without help from the developer. They just have to roll back the update! On the other hand customer CAN'T fix the first issue (e.g. new hardware).