3 ms·

Leaving dependency management to distros can cause problems when they upgrade a package to a new one that breaks the old API or when they lack a package for a l

Leaving dependency management to distros can cause problems when they upgrade a package to a new one that breaks the old API or when they lack a package for a library you need. Dependency isolation is something that Java got right: compile everything into one jar and then deployment is just copying the jar and executing it. The drawback is that you are responsible for security vulnerabilities in the libraries you install.

jessaustin 14y ago
Dependency isolation is something that Java got right: compile everything into one jar and then deployment is just copying the jar and executing it. So that's why jars are always 100 MB! I don't think the python community will ever perceive this as the "right" way to distribute libraries. (Actually I'm not sure even java thinks jars are the right solution for libraries.) You'd probably get more agreement if it were declared the right way to do AMIs or buildout recipes or whatever. The drawback is that you are responsible for security vulnerabilities in the libraries you install. It's one thing to say that the sysadmin is responsible for security, but it's another to make sure they have access to fifty rebuilt binary distributions every time a library upon which those depend has a security update. There's dependency isolation and then there's dependency isolation.
- calpaterson 14y ago
  > So that's why jars are always 100 MB! I don't think the python community will ever perceive this as the "right" way to distribute libraries. I'm not advocating it as the right way to distribute libraries. It's the right way to deploy applications. Compiling everything into one simplifies deployment. It does not simplify public distribution. > the sysadmin is responsible for security [...] It just means that whoever is responsible for security (which should be operations _and_ development, IMO) need a list of the libraries used as part of an application. In Python this is normally stored in the file "requirements" in the root of the source tree. Java projects have similar things, so does Haskell.
  - jessaustin 14y ago
    I'm not advocating it as the right way to distribute libraries. It's the right way to deploy applications. OK, I agree that's a different case, one for which jars may be appropriate whenever you don't have access to an OS-level package manager. But when is that? When using Windows, but not in the enterprise? Surely most would avoid that grim situation. Since I use apt or the equivalent to install and update apps (unless I have a reason to be closer to the current version), I primarily think of python distributions as providing libraries, although of course they may include applications as well. It just means that whoever is responsible for security (which should be operations _and_ development, IMO) need a list of the libraries used as part of an application. Of course it's nice when the applications one installs are supported by developers in the same organization, but it's a rare luxury that doesn't obtain for the typical sysadmin. Even in that case, however, aren't you proposing to make a lot of work for yourself that your package manager is happy to do instead?
lawnchair_larry 14y ago
The drawback is that you are responsible for security vulnerabilities in the libraries you install. That is a much larger problem than most people realize. It makes vulnerable dependencies fairly impossible to deal with. If an OpenSSL bug comes out, I upgrade OpenSSL on all systems in my enterprise. Everything linked to it is automagically taken care of. If a vulnerable library is buried into jar files (or whatever equivalent in your language of choice), I'm screwed. You'll never find those, and there is no assurance that your systems are patched. If I put on my developer or end-user hat, I totally agree with you. But for most software, this is dangerous.

jessaustin 14y ago

Dependency isolation is something that Java got right: compile everything into one jar and then deployment is just copying the jar and executing it. So that's why jars are always 100 MB! I don't think the python community will ever perceive this as the "right" way to distribute libraries. (Actually I'm not sure even java thinks jars are the right solution for libraries.) You'd probably get more agreement if it were declared the right way to do AMIs or buildout recipes or whatever. The drawback is that you are responsible for security vulnerabilities in the libraries you install. It's one thing to say that the sysadmin is responsible for security, but it's another to make sure they have access to fifty rebuilt binary distributions every time a library upon which those depend has a security update. There's dependency isolation and then there's dependency isolation.

calpaterson 14y ago
> So that's why jars are always 100 MB! I don't think the python community will ever perceive this as the "right" way to distribute libraries. I'm not advocating it as the right way to distribute libraries. It's the right way to deploy applications. Compiling everything into one simplifies deployment. It does not simplify public distribution. > the sysadmin is responsible for security [...] It just means that whoever is responsible for security (which should be operations _and_ development, IMO) need a list of the libraries used as part of an application. In Python this is normally stored in the file "requirements" in the root of the source tree. Java projects have similar things, so does Haskell.
- jessaustin 14y ago
  I'm not advocating it as the right way to distribute libraries. It's the right way to deploy applications. OK, I agree that's a different case, one for which jars may be appropriate whenever you don't have access to an OS-level package manager. But when is that? When using Windows, but not in the enterprise? Surely most would avoid that grim situation. Since I use apt or the equivalent to install and update apps (unless I have a reason to be closer to the current version), I primarily think of python distributions as providing libraries, although of course they may include applications as well. It just means that whoever is responsible for security (which should be operations _and_ development, IMO) need a list of the libraries used as part of an application. Of course it's nice when the applications one installs are supported by developers in the same organization, but it's a rare luxury that doesn't obtain for the typical sysadmin. Even in that case, however, aren't you proposing to make a lot of work for yourself that your package manager is happy to do instead?

lawnchair_larry 14y ago

The drawback is that you are responsible for security vulnerabilities in the libraries you install. That is a much larger problem than most people realize. It makes vulnerable dependencies fairly impossible to deal with. If an OpenSSL bug comes out, I upgrade OpenSSL on all systems in my enterprise. Everything linked to it is automagically taken care of. If a vulnerable library is buried into jar files (or whatever equivalent in your language of choice), I'm screwed. You'll never find those, and there is no assurance that your systems are patched. If I put on my developer or end-user hat, I totally agree with you. But for most software, this is dangerous.