0

So in the current age of Software Engineering, code reuse is so important that modern languages have some form of dependency management. Dartlang achieves this through the use of Pub. However, pub has taken the approach of using shared dependencies, meaning that if 2 or more libraries have a common dependency, that dependency will be downloaded once and the libraries share it... This of course has led to a very vexing problem.

This is something that happens extremely often. You are working on a project that requires n+1 libraries. It is fairly common for some of the libraries to have the same dependency. It is also very likely that they depend on DIFFERENT versions of said dependency. It is so bad, that pub had to give you the option to override dependencies. You'd think that one would maybe just use the latest version of said library, but code is always in flux so different versions tend to have breaking changes...

Pub tries to work out a compromise itself, but it usually just gives up saying it can't do it, leaving you to manually try something with the overrides mentioned above. Often times you spend more time trying to mix and match versions of your libraries till you get a pair that will seemingly play nice with each other. It is also extremely vexing when an update was pushed to one library that fixes a bug that was affecting your project, but you don't want to update because that would change the needed versions of the shared dependency and thus would break your other libraries >.>

A good example of this crap is with Polymer and Angular. I know that their code is still in flux, but I can tell you that alot of people would love to use them both together! Polymer and Angular a two independent projects and it would be very unreasonable to expect their respective communities to make sure that all their versions remain compatible with each other.

I come from a Java background. Java does not have built in dependency management. However, the community made two projects that are more or less industry needed if you want to make a large java project. They are Maven and ivy. Why this problem doesn't exist over on their side is because they decided that each dependency should be isolated from the others. If pub were to also take that approach, this problem would disappear over night!

Sorry for the rant, but right now I am asking, is there a way to make pub behave more like Maven or Ivy? If not, is there a third-party dependency manager that does same?

Marc Byfield
  • 510
  • 4
  • 14
  • Wait, what do you think happens with Maven or Ivy when there exist Java libraries A and B, which depend on version C1 and C2 of C? – Jean Hominal Sep 24 '14 at 13:32
  • The point I am driving at, is that even with Maven and Ivy's dependency resolution, the same issues can be encountered in Java (Maven and Ivy also offer ways to override dependencies). The reason why the situation is less problematic is because the Java ecosystem is 15 to 20 years more mature, and as such backwards compatibility is taken more seriously. And there are solutions that have been developed to address these issues, such as [jarjar](http://code.google.com/p/jarjar/) or [OSGi](http://en.wikipedia.org/wiki/OSGi), both of which I would classify as "only use it if you *really* need it". – Jean Hominal Sep 24 '14 at 14:00
  • 2
    It's not just that Polymer and Angular are in flux, it's that libraries they depend on are also in flux and non-backward compatible, so they have to use narrow version constraints that don't match up with each other. All of these libraries are not even at version 1 yet. It's an odd and annoying situation, but it will sort itself out once libraries start to mature. It would be nice to not have to wait until then though. – Pixel Elephant Sep 24 '14 at 15:04
  • 1
    At least Dart addressed dependencies very early on and gave us some sort of way to manage them. – Argenti Apparatus Sep 24 '14 at 17:04

1 Answers1

1

That has nothing to do with the dependency resolution but is caused by the Dart VM which doesn't support loading two different versions of the same library.

A big advantage is that this keeps the code size small which is rather important on the client side.

Günter Zöchbauer
  • 623,577
  • 216
  • 2,003
  • 1,567
  • 1. The problem does not have to be solved at the VM level - it would be possible for a build system to engineer a way to support multiple versions of the same library side-by-side that would e.g. on namespace aliasing. 2. A more fundamental issue is the additional complexity (understanding, debugging) that is added by any system supporting multiple versions of the same library. – Jean Hominal Sep 24 '14 at 13:45
  • Currently this is all hardcoded in `pub` and other tools. You wouldn't be able to use ´pub` if you want a different behavior here. I guess any attempt in that direction would cause so many other troubles that it would be abandoned very early. – Günter Zöchbauer Sep 24 '14 at 13:47
  • The original post is explicitly asking for an alternative to `pub`! Or a way to configure `pub` to behave differently (which does not exist, which could be part of the answer) – Jean Hominal Sep 24 '14 at 13:49
  • But `pub` does more than just dependency resolution. I can ensure you that there is currently no alternative not even plans to make any are discussed anywhere in the Dart communities I follow. Combining Angular and Polymer is the first time this issue caused some notable public discussion. – Günter Zöchbauer Sep 24 '14 at 13:52
  • Günter, I am sorry for being the first to have used an exclamation point. I agree with you, and think that your last comment could be an excellent answer to the OP's question. – Jean Hominal Sep 24 '14 at 14:03
  • It is a valid and reasonable question, nothing to be sorry about. – Günter Zöchbauer Sep 24 '14 at 14:06
  • 1
    It seem to me that part of the (general, not just Dart) problem is that package developers can declare a narrow version dependency rather than a maximally wide one. A best practice for library package developers may be to initially declare a dependency on another package like this: >= x.y.z, < x+1.0.0, where x.y.z is the earliest version that works. Later versions with the same x should be backwards compatible (according to Semantic Versioning). Version x+1 would be generally non-backward compatible with version x. Obviously, testing with different versions of each dependency would be best. – Argenti Apparatus Sep 24 '14 at 17:18
  • So currently, the developer will just have to bare the pain of trial and erroring the version numbers till you get a combination that works. – Marc Byfield Sep 25 '14 at 00:07
  • 1
    Or wait until the packages are stable enough to work together without troubles. If you don't want to cope with such things you shouldn't work with alpha/pre-alpha releases. – Günter Zöchbauer Sep 25 '14 at 04:04