support for _2.10 suffix by default in launchconfig

[eugene yokota]

Hi,

Last night I found a hack to use _2.10 suffixed app from sbt 0.11.3 launcher aka conscript 0.4.1: https://groups.google.com/d/topic/conscript-scala/GL7eKtK7IKs/discussion

In short you set app.cross-versioned to false so you can manually set the suffix yourself.

 

[app]

version: 1.0.1

org: org.scalaxb

name: scalaxb_2.10

class: scalaxb.compiler.SbtApp

cross-versioned: false

If sbt 0.12 style binary versioning is the de facto standard, maybe launchconfig for sbt should also accept it without the workaround.

For example, it could add another setting called "binary-versioned", and set it to "true" by default. binaryScalaVersion can calculate suffix for 2.9.x and 2.10.x.

conscript would need to update the launcher to 0.13 to take advantage of this behavior, but it would be there in the future.

-eugene

[Doug Tangren]

nice eugene!

 

-eugene

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/dhVOcMkS3lUJ.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.

[Mark Harrah]

On Thu, 24 Jan 2013 10:58:17 -0800 (PST)
eugene yokota <eed3...@gmail.com> wrote:

> Hi,
>
> Last night I found a hack to use _2.10 suffixed app from sbt 0.11.3
> launcher aka conscript
> 0.4.1: https://groups.google.com/d/topic/conscript-scala/GL7eKtK7IKs/discussion
> In short you set app.cross-versioned to false so you can manually set the
> suffix yourself.
>
>
> [app]
> version: 1.0.1
> org: org.scalaxb
> name: scalaxb_2.10
> class: scalaxb.compiler.SbtApp
> cross-versioned: false
>
>
> If sbt 0.12 style binary versioning is the de facto standard, maybe
> launchconfig for sbt should also accept it without the workaround.
> For example, it could add another setting called "binary-versioned", and
> set it to "true" by default. binaryScalaVersion can calculate suffix for
> 2.9.x and 2.10.x.

Yes, something should be done here. Are you suggesting the binary-versioned property mainly for manual control as well as including the logic for binaryScalaVersion in the launcher?

> conscript would need to update the launcher to 0.13 to take advantage of
> this behavior, but it would be there in the future.

Yes, the launcher should be able to launch old versions so this shouldn't be a problem, right?

-Mark

[eugene yokota]

On Thu, Jan 24, 2013 at 4:26 PM, Mark Harrah <dmha...@gmail.com> wrote:

> If sbt 0.12 style binary versioning is the de facto standard, maybe
> launchconfig for sbt should also accept it without the workaround.
> For example, it could add another setting called "binary-versioned", and
> set it to "true" by default. binaryScalaVersion can calculate suffix for
> 2.9.x and 2.10.x.

Yes, something should be done here.  Are you suggesting the binary-versioned property mainly for manual control as well as including the logic for binaryScalaVersion in the launcher?

Yes. Having binary-versioned allows _2.10.0 suffix to be used. Given the following,

[app]

version: 1.0.1

org: org.scalaxb

name: scalaxb

(crossVersioned, binaryVersioned) match {

  case (false, _) => "scalaxb"

  case (true, true) => "scalaxb_2.10"

  case (true, false) => "scalaxb_2.10.0"

}

> conscript would need to update the launcher to 0.13 to take advantage of
> this behavior, but it would be there in the future.

Yes, the launcher should be able to launch old versions so this shouldn't be a problem, right?

The launcher-interface's binary compatibility have been holding up well.

Until recently I used to use "org.scala-tools.sbt" % "launcher-interface" % "0.7.4" % "provided".

-eugene

[Mark Harrah]

On Thu, 24 Jan 2013 16:44:53 -0500
eugene yokota <eed3...@gmail.com> wrote:

> On Thu, Jan 24, 2013 at 4:26 PM, Mark Harrah <dmha...@gmail.com> wrote:
> >
> > > If sbt 0.12 style binary versioning is the de facto standard, maybe
> > > launchconfig for sbt should also accept it without the workaround.
> > > For example, it could add another setting called "binary-versioned", and
> > > set it to "true" by default. binaryScalaVersion can calculate suffix for
> > > 2.9.x and 2.10.x.
> >
> > Yes, something should be done here. Are you suggesting the
> > binary-versioned property mainly for manual control as well as including
> > the logic for binaryScalaVersion in the launcher?
> >
>
> Yes. Having binary-versioned allows _2.10.0 suffix to be used. Given the
> following,
>
> [app]
> version: 1.0.1
> org: org.scalaxb
> name: scalaxb
>
>
> (crossVersioned, binaryVersioned) match {
> case (false, _) => "scalaxb"
> case (true, true) => "scalaxb_2.10"
> case (true, false) => "scalaxb_2.10.0"
> }

Actually, perhaps "binary", "none", and "full" should be the expected values for crossVersioned, with "true" and "false" corresponding to "full" and "none", respectively. If there is an interface problem, add a new method and implement the old method approximately.

> > conscript would need to update the launcher to 0.13 to take advantage of
> > > this behavior, but it would be there in the future.
> >
> > Yes, the launcher should be able to launch old versions so this shouldn't
> > be a problem, right?
> >
>
> The launcher-interface's binary compatibility have been holding up well.
> Until recently I used to use "org.scala-tools.sbt" % "launcher-interface" %
> "0.7.4" % "provided".

Ha, nice!

-Mark

> -eugene
>
> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.

[Josh Suereth]

Yeah, although I'm starting to not cross version anything I use the launcher for.

E.g. I wanted to use the launcher to pull down an app I had snuck in an sbt plugin, but couldn't figure out how to specify additional properties (like sbtVersion) for the resolving, so I gave up.

Maybe we could add a generic extra properties and then build the scala version stuff on top?

I'm almost comfortable enough in the launcher to do that work....

[Mark Harrah]

On Fri, 25 Jan 2013 15:52:44 -0500
Josh Suereth <joshua....@gmail.com> wrote:

> Yeah, although I'm starting to not cross version anything I use the
> launcher for.

If you are writing an application that only runs against one version of Scala and isn't consumed by anyone, I think that is the right thing. You only have to do it for the application jar because that is the only one the launcher needs to handle specially.

> E.g. I wanted to use the launcher to pull down an app I had snuck in an sbt
> plugin, but couldn't figure out how to specify additional properties (like
> sbtVersion) for the resolving, so I gave up.
>
> Maybe we could add a generic extra properties and then build the scala
> version stuff on top?

I don't think it is a problem to support more dependency information. I don't think it can be used for the Scala version suffix though. It doesn't work for Maven poms and repositories, which are supported.

-Mark

> Visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[eugene yokota]

This reminds me that I should confess there's a launchconfig parser/generator in conscript that I hacked a while back:

https://github.com/n8han/conscript/blob/b2f6f18fa7991978b086ffd2017064ae521cde84/src/main/scala/launchconfig.scala

It was to rewrite downloaded lauchconfig's app.version so the user can say `cs user/project/1.0.0`.

Later we added another override to include/excude local repos.

If we are changing stuff around launchconfig, it would be nice if there's a generator for it along side the parser,

so it gets DRY.

-eugene

[eugene yokota]

On Thursday, January 24, 2013 4:56:10 PM UTC-5, Mark Harrah wrote:

> (crossVersioned, binaryVersioned) match {
>   case (false, _) => "scalaxb"
>   case (true, true) => "scalaxb_2.10"
>   case (true, false) => "scalaxb_2.10.0"
> }

Actually, perhaps "binary", "none", and "full" should be the expected values for crossVersioned, with "true" and "false" corresponding to "full" and "none", respectively.  If there is an interface problem, add a new method and implement the old method approximately. 

Am I expected to maintain source-level compatibility for launcher?

Normally plugin authors won't need anything from the launcher, and it's a new major release anyway.

Also are you ok with launcher getting bigger with ivy (and with it regex library etc) module that does the sbt.CrossVersion._?

-eugene 

[eugene yokota]

On Saturday, January 26, 2013 11:50:33 AM UTC-5, eugene yokota wrote:

On Thursday, January 24, 2013 4:56:10 PM UTC-5, Mark Harrah wrote:

> (crossVersioned, binaryVersioned) match {
>   case (false, _) => "scalaxb"
>   case (true, true) => "scalaxb_2.10"
>   case (true, false) => "scalaxb_2.10.0"
> }

Actually, perhaps "binary", "none", and "full" should be the expected values for crossVersioned, with "true" and "false" corresponding to "full" and "none", respectively.  If there is an interface problem, add a new method and implement the old method approximately. 

Am I expected to maintain source-level compatibility for launcher?

Never mind. It became clear that you meant the Java interface once I started coding:

public boolean crossVersioned();

public String crossVersionedString();

Also are you ok with launcher getting bigger with ivy (and with it regex library etc) module that does the sbt.CrossVersion._?

Bringing ivySub didn't work, because ivySub depends on launchSub % "test" -> "test".

I might have to refactor out binaryScalaVersion etc to  an AbstractCrossVersion trait outside and use some kind of clever aliasing to avoid implementation duplication.

-eugene