5 ms·

Actually what is insane is to have your production code do anything else. "pip install foo" and similar schemes open your code up to the following problems: -

Actually what is insane is to have your production code do anything else. "pip install foo" and similar schemes open your code up to the following problems: - incompatibilities that were introduced in the version 1.2.1 while you've only tested your code with 1.2 - the host is down so you can't compile your own code because your dependency is not available - the host is hacked and "foo" was replaced with "malicious foo" - exponential increase of testing (you really should test with all version of your dependencies you use) Ultimately, I don't understand the doom and gloom point of view. C, C++, Java, C# etc. programmers have been pulling dependencies in their repos for ages. In my SumatraPDF I have 12 dependencies. I certainly prefer to manually update them from time to time than to have builds that work on my machine but fail for other people or many other problems that are a result of blindly pulling third party code.

lucian1900 13y ago
> - incompatibilities that were introduced in the version 1.2.1 while you've only tested your code with 1.2 Which is why you pin dependencies to specific versions. > - the host is down so you can't compile your own code because your dependency is not available Which is why you have (caching) proxy and use mirrors. > - the host is hacked and "foo" was replaced with "malicious foo" Which is why you use GPG signing. (sadly, Python lacks in this respect). > - exponential increase of testing (you really should test with all version of your dependencies you use) Which is why you only use a specific version.
d0mine 13y ago
- you can freeze the version: foo==1.2.1 - you don't need the internet to install dependencies. There are many options e.g., a locally cached tarball will do (no need to download the same file multiple times). Note: your source tree is not the place to put it (the same source can be built, tested, staged, deployed using different dependencies versions e.g., to support different distributions where different versions are available by default) - if your build infrastructure is compromised; you have bigger problems than just worrying about dependencies - you don't need to pull dependencies and dependencies of dependencies, etc into your source tree to keep the size of the test matrix in check even if you decided to support only a single version for each your dependencies. As usual different requirements may lead to different trades off. There could be circumstances where to vendor dependencies is a valid choice but not due to the reasons you provided
tiredofcareer 13y ago
None of the things you listed are problems. The other comment demonstrates solutions to all of them, and I do not understand your fourth bullet point in context at all. > C, C++, Java, C# etc. programmers have been pulling dependencies in their repos for ages. I'm not making this up: in my career, I have never worked on a project where this is the case, and I've worked for shops that write in three of those languages. > I certainly prefer to manually update them from time to time than to have builds that work on my machine but fail for other people That's your choice, and it's a little bit different because I'm assuming "other people" are end users -- those that want to recompile SumatraPDF from source for some bizarre reason -- not developers. Fixing a broken build is a skill that every developer should have, but not an end user. Once I learned how to write software, I never came across a situation as an end user compiling an open-source Unix package that I could not solve myself. The opinion I'm sharing here is related to developing on a team, not distributing source for end-user consumption. It sounds like you don't develop SumatraPDF with many other people, either. Nothing like merge failures on a huge dependency that I didn't write to ruin a Monday. Also, wait, SumatraPDF is built with dependencies in the codebase? What if a zero-day is discovered in one of your dependencies while you're on vacation for a month; what do distribution maintainers do? Sigh? Patch in the distribution and get to suffer through a merge when you return?
- mercurial 13y ago
  > C, C++, Java, C# etc. programmers have been pulling dependencies in their repos for ages. The first time I worked on a C# project started in an age where nu-get was not widespread, I saw with dismay a "lib" directory with vendored DLLs. It does happen.
  - bruceboughton 13y ago
    Why dismay?
    - mercurial 13y ago
      Many reasons: - Binary artifacts under version control is no-no for me, unless we're talking assets. Third-party libraries are not assets. - Where do these DLLs come from? How do I know it's not some patched version built by a developer on his machine? I have no guarantee the library can be upgraded to fix a security issue. - Will the DLLs work on another architecture? - What DLL does my application need, and which ones are transitive dependencies? That's many questions I shouldn't have to ask, because that's what a good package management system solves for you.

lucian1900 13y ago

> - incompatibilities that were introduced in the version 1.2.1 while you've only tested your code with 1.2 Which is why you pin dependencies to specific versions. > - the host is down so you can't compile your own code because your dependency is not available Which is why you have (caching) proxy and use mirrors. > - the host is hacked and "foo" was replaced with "malicious foo" Which is why you use GPG signing. (sadly, Python lacks in this respect). > - exponential increase of testing (you really should test with all version of your dependencies you use) Which is why you only use a specific version.

d0mine 13y ago

- you can freeze the version: foo==1.2.1 - you don't need the internet to install dependencies. There are many options e.g., a locally cached tarball will do (no need to download the same file multiple times). Note: your source tree is not the place to put it (the same source can be built, tested, staged, deployed using different dependencies versions e.g., to support different distributions where different versions are available by default) - if your build infrastructure is compromised; you have bigger problems than just worrying about dependencies - you don't need to pull dependencies and dependencies of dependencies, etc into your source tree to keep the size of the test matrix in check even if you decided to support only a single version for each your dependencies. As usual different requirements may lead to different trades off. There could be circumstances where to vendor dependencies is a valid choice but not due to the reasons you provided

tiredofcareer 13y ago

None of the things you listed are problems. The other comment demonstrates solutions to all of them, and I do not understand your fourth bullet point in context at all. > C, C++, Java, C# etc. programmers have been pulling dependencies in their repos for ages. I'm not making this up: in my career, I have never worked on a project where this is the case, and I've worked for shops that write in three of those languages. > I certainly prefer to manually update them from time to time than to have builds that work on my machine but fail for other people That's your choice, and it's a little bit different because I'm assuming "other people" are end users -- those that want to recompile SumatraPDF from source for some bizarre reason -- not developers. Fixing a broken build is a skill that every developer should have, but not an end user. Once I learned how to write software, I never came across a situation as an end user compiling an open-source Unix package that I could not solve myself. The opinion I'm sharing here is related to developing on a team, not distributing source for end-user consumption. It sounds like you don't develop SumatraPDF with many other people, either. Nothing like merge failures on a huge dependency that I didn't write to ruin a Monday. Also, wait, SumatraPDF is built with dependencies in the codebase? What if a zero-day is discovered in one of your dependencies while you're on vacation for a month; what do distribution maintainers do? Sigh? Patch in the distribution and get to suffer through a merge when you return?

mercurial 13y ago
> C, C++, Java, C# etc. programmers have been pulling dependencies in their repos for ages. The first time I worked on a C# project started in an age where nu-get was not widespread, I saw with dismay a "lib" directory with vendored DLLs. It does happen.
- bruceboughton 13y ago
  Why dismay?
  - mercurial 13y ago
    Many reasons: - Binary artifacts under version control is no-no for me, unless we're talking assets. Third-party libraries are not assets. - Where do these DLLs come from? How do I know it's not some patched version built by a developer on his machine? I have no guarantee the library can be upgraded to fix a security issue. - Will the DLLs work on another architecture? - What DLL does my application need, and which ones are transitive dependencies? That's many questions I shouldn't have to ask, because that's what a good package management system solves for you.