10

I know why this is good in general: faster security fixes, easier packaging, more features. However, I'm trying to persuade some co-workers that we don't need to bundle a library with our program. It will not work without this library, but the library has been stable for a while now and will remain so for the foreseeable future. I don't see any reason NOT to unbundle it.

What arguments could I use to persuade them?

My specific situation is this: I'm working on SymPy, which is an open-source Python library for symbolic mathematics. A core part of it is mpmath, which is a library for multi-prevision floating point arithmetic. SymPy doesn't work without mpmath, there is no alternative. As such, it has been bundled with SymPy since the start (I was told that there were usually small incompatibilities to fix every time a new version is imported). It should also be noted that the developer of mpmath used to be involved in SymPy development. There is now an issue on unbundling mpmath, you can read it all here.

To summarize the discussion there:

Unbundle:

  • Somewhat easier porting to Python 3 (minor argument IMHO)

  • Easier packaging for distributions

  • Faster (security) feature updates to users

  • "Packaging and handling dependencies are hard problems, but they are solved. This is definitely not an area where we should do our own thing."

Keep bundling:

  • Installation. It's easy on Linux, harder on Mac and very hard on Windows. Lack of su access and other problems.

  • it is an integral part of SymPy, i.e. sympy does not work without it (at all)

  • there is no other package, that can do the job of mpmath

  • "When I, as a user, download sympy, I expect it to just work."

That's my specific situation, but I'd accept an answer that provides a good, general answer as well.

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
VPeric
  • 627
  • You need to provide more info with your specific situation to get a better answer. For example, what environment are you planning to run it? Will it be exposed to the internet? – tshepang Jun 15 '11 at 18:55
  • Is your application open source? – Anton Barkovsky Jun 15 '11 at 19:00
  • @Anton Yes, it's SymPy, an open-source Python library for symbolic mathematics. I'm working in it as a GSoC student (full disclosure :)). – VPeric Jun 15 '11 at 19:05
  • @Tshepang The discussion can be seen at: http://code.google.com/p/sympy/issues/detail?id=2482 – VPeric Jun 15 '11 at 19:06
  • @VPeric: It would be extra nice to summarise that discussion, just to save the time for those willing to answer your question. – tshepang Jun 15 '11 at 19:22
  • You really need to mention in your post that you are talking about a library that isn't yet split away. At least that's what the discussion implies. – tshepang Jun 15 '11 at 19:36
  • @Tshepang I've written a summary, is that better? And yes, it isn't split away yet in master, but there's a branch that does just that and it works fine. – VPeric Jun 15 '11 at 19:51

6 Answers6

6

On top of the advantages you mentioned (security, packaging, features), I can think of some more:

  • Someone who would find the functionality useful for another program would not need to do the work of splitting it away. That is if she even knows if the functionality exists in your project in the form of a library in the first place. This depends on how well it's designed... if your project is modular enough.

  • In the case of this being useful for other projects, this would reduce the size of disc usage in general (e.g. only one copy of the code).

  • This would improve the quality of your code, forcing you to do some (much-needed) refactoring. As in the first point above, this also depends on the quality of your code.

  • Increasing the number of users of the library (if it's split away) would help make it more generic, which will likely improve it's quality as well.

tshepang
  • 65,642
  • 1
    All good points. I suppose it could be read as "future-proofing": few of your points apply currently (mpmath is used in only a couple other projects at the moment), but it's easy to see that each of your points gains value for every new project using mpmath. – VPeric Jun 15 '11 at 20:12
5

Yet another answer, but one I consider to be the most important (just my own personal opinion), though the others are all good answers as well.

Packaging the lib separately allows the lib to be updated without the need to update the application. Say theres a bug in the lib, instead of just being able to update the lib, you'd have to update the entire application. Which means your application would need a version bump without its code even having changed, just because of the lib.

phemmer
  • 71,831
  • 1
    That is an important point, and it's part of why many distributions dislike having libraries bundled with programs; for example Debian has a policy of not bundling a library with an executable or statically linking a library unless it can only ever be used by that particular program (or, for static linking, those cases where dynamic linking is not supported). – Gilles 'SO- stop being evil' Jun 16 '11 at 07:52
  • In the end, this is perhaps the most important point. I agree with the other answers as well, but I had to pick just one. :) – VPeric Jun 26 '11 at 11:12
4

While advantages are obvious, ease of deploying seems to be the main argument for shipping library together with program in your case.

Here's some more arguments against bundling:

  • In Linux, it's the distribution maintainer's job to ensure that your library works well with its dependencies. Most users will in any case download the library using the distribution's package manager. Those who are using trunk usually will not mind spending time on configuring the library anyway.

  • In Windows and Mac OS, Python package managers like pip are usually used anyway, since installing libraries by hand is cumbersome.

  • There have even been arguments about hard-deploying to Google app engine, but not all web frameworks run on it. Many even require porting, disk space for libraries is limited, and it's web application hosting after all! It's unlikely for web application to use symbolic maths.

  • Nobody prevents you from displaying clean error messages if the dependency isn't available or has the wrong version.

  • People often hate it when the program considers itself more clever than they are. Let users take care of their own system.

tshepang
  • 65,642
Anton Barkovsky
  • 1,509
  • Can you explain the last point. I can't tell if it's an argument for/against bundling. – tshepang Jun 15 '11 at 20:04
  • 3
    I understand it as against bundling - the users want to install what they want, not have me force a particular version on them. – VPeric Jun 15 '11 at 20:08
3

The proper way to handle unbundled in a windows installer package would be to have the preinst test for the library's existence, and if it's not present to offer to install it from the library package that you include in the software installer package. I'm pretty sure most GTK apps that have windows ports do something along these lines -- I know pidgin does.

Shadur-don't-feed-the-AI
  • 31,260
3

One size doesn't have to fit all.

For source distributions, if you bundle, packagers on many distributions (at least of the Debian and Fedora heritages) will have to do additional work to disable or remove the bundling, as package policies for those platforms prohibit or at least strongly discourage bundling. Therefore, by bundling you are creating more work for your downstream with very little benefit. Might that argument have some weight?

Binary distributions (if you provide them) could go either way; bundling probably makes sense for those, as they aren't used by downstream.

But there's no reason why you can't make the opposite decision and bundle for Windows and Mac installers.

Michael Ekstrand
  • 2,124
  • 1
    While I agree in general, it does create an extra burden (however small) that means that probably no one would back this solution. – VPeric Jun 23 '11 at 07:34
2

Bundling vs. depending is an old debate in the packaging world. This document tells about these two schools of thought: http://www.aosabook.org/en/packaging.html

merwok
  • 121
  • 2
    This was an interesting read, but it talks more about the implementation details and various Python specifics than the general philosophy. – VPeric Jun 30 '11 at 07:36