Dispatch (and other lib) versions used by plugins

[eugene yokota]

Hi all,

In 0.13.0-RC4 Mark mentioned something interesting:

> Note that you can put all of these together in a plugins.sbt file except for ls-sbt and it will at least load.  dispatch 0.8.8 and 0.8.10 are incompatible, which causes ls-sbt to not load.

As a plugin author, should I be aware of which Dispatch version I should be using?

If so, should we decide on one or two Dispatch versions that we all use throughout 0.13 series?

- 0.8.10 is the latest version of the Dispatch classic. It moved the package name to dispatch.classic so it could be used together with reboot.

  dispatch-lift-json is not there for _2.10.

- 0.11.0 is the latest version of the Dispatch reboot. It's async and returns Future.

  dispatch-lift-json is there for _2.10 as well as dispatch-json4s.

I guess the same applies for any other libraries we might use like Scalaz, but Dispatch would be a likely contention.

-eugene

[Josh Suereth]

Yeah.  I'm using dispatch in the pgp library for the PGP plugin.  Maybe in the plugin best practices we can list "shared libraries" that we all use, so we don't run into issues.  We kinda all need to use compatible libraries.

It's really *only* a problem if Ivy evicts one version for another *and those versions are incompatible*.   This is binary compatibility fun, and perhaps we just need to pick libraries which retain it during minor versions.   Dispatch 0.8.8->0.8.10 broke binary compatibility, and ivy is evicting one for the other (which is why we have issues).

The social problem (of requesting that dispatch alter its version scheme so binary compatibility guarantees match Ivy's eviction practices) may be easier to solve.

Again, this is an insidious issue if we don't start offering binary compatibility guarantees....

-eugene

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simple-build-t...@googlegroups.com.
To post to this group, send email to simple-b...@googlegroups.com.
Visit this group at http://groups.google.com/group/simple-build-tool.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Doug Tangren]

On Wed, Jul 31, 2013 at 7:46 AM, Josh Suereth <joshua....@gmail.com> wrote:

Yeah.  I'm using dispatch in the pgp library for the PGP plugin.  Maybe in the plugin best practices we can list "shared libraries" that we all use, so we don't run into issues.  We kinda all need to use compatible libraries.

It's really *only* a problem if Ivy evicts one version for another *and those versions are incompatible*.   This is binary compatibility fun, and perhaps we just need to pick libraries which retain it during minor versions.   Dispatch 0.8.8->0.8.10 broke binary compatibility, and ivy is evicting one for the other (which is why we have issues).

The social problem (of requesting that dispatch alter its version scheme so binary compatibility guarantees match Ivy's eviction practices) may be easier to solve.

Again, this is an insidious issue if we don't start offering binary compatibility guarantees....

bintray-sbt uses bintry which uses dispatch-json4s-native  0.10.1, in the process of refactoring ls to use dispatch-json4s-native 0.11.0. was planning to update bintry to use 0.11.0 as well. to sync them up. moving to reboot means we can use the same plugin version in 0.12 because dispatch reboot targets scala 2.9.3+ ( for the newer future interface )

[Roman Timushev]

Hi,

In sbt-updates I had to work around such conflicts by repacking dependencies into subpackage (https://github.com/rtimush/sbt-updates/blob/master/proguard.sbt). It is not a perfect solution though, so having a consensus on versions among 0.13 plugins seems to be a good idea.

May be one day sbt will be able to load plugins with independent classloaders to avoid such issues.

[Josh Suereth]

On Tue, Aug 6, 2013 at 10:49 AM, Roman Timushev <rti...@gmail.com> wrote:

Hi,

In sbt-updates I had to work around such conflicts by repacking dependencies into subpackage (https://github.com/rtimush/sbt-updates/blob/master/proguard.sbt). It is not a perfect solution though, so having a consensus on versions among 0.13 plugins seems to be a good idea.

May be one day sbt will be able to load plugins with independent classloaders to avoid such issues.

Not sure this is practical since a users project compiles against plugins.  i.e. Plugins make up the set of libraries you use to create your build.  It's the same issue of binary compatibility as any ecosystem of libraries.  Just exacerbated by Scala.  The Java ecosystem seems to have gone the route of shading, like your repackaging approach.  Then there's OSGi (classloader approach).  I'm rather curious what a build tool would look like on OSGi.