port scala.meta to 2.10 #295

Closed
xeno-by opened this Issue Oct 28, 2015 · 36 comments

Comments

Projects
None yet
9 participants
@xeno-by
Member

xeno-by commented Oct 28, 2015

One of the immediate use cases for scala.meta is codegen from within an sbt plugin. Unfortunately, there we're pretty much stuck with 2.10, so it would be nice to have a build for 2.10 (/cc @densh @JanBessai)

While porting scalahost to 2.10 is pretty much insane (given that we don't even have a working scalahost for 2.11), the standalone parts of scala.meta may very well be compileable with 2.10.

@densh

This comment has been minimized.

Show comment
Hide comment
@densh

densh Oct 29, 2015

Member

Is there any information on when sbt will migrate to 2.11? Maybe it's easier to wait for that to happen.

Member

densh commented Oct 29, 2015

Is there any information on when sbt will migrate to 2.11? Maybe it's easier to wait for that to happen.

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Oct 29, 2015

Member

Iirc that'll be with the release of sbt 1.0. /cc @eed3si9n

Member

xeno-by commented Oct 29, 2015

Iirc that'll be with the release of sbt 1.0. /cc @eed3si9n

@xeno-by xeno-by added this to the 0.1 milestone Apr 3, 2016

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Apr 4, 2016

Member

I tried porting the stable parts of scala.meta to 2.10, but even that was too hard. It turns out, we have several dozen macros in foundation, and a bunch of them is using the 2.11 API. Unfortunately, macro-compat has proven insufficient, so I'm putting this on hold or the time being.

Member

xeno-by commented Apr 4, 2016

I tried porting the stable parts of scala.meta to 2.10, but even that was too hard. It turns out, we have several dozen macros in foundation, and a bunch of them is using the 2.11 API. Unfortunately, macro-compat has proven insufficient, so I'm putting this on hold or the time being.

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Apr 4, 2016

Member

Also, this port should introduce a Scala210 dialect and change the currentDialect macro to pick the new dialect up when necessary.

Member

xeno-by commented Apr 4, 2016

Also, this port should introduce a Scala210 dialect and change the currentDialect macro to pick the new dialect up when necessary.

@xeno-by xeno-by modified the milestone: 0.1 Apr 4, 2016

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Apr 6, 2016

Contributor

Does "Contributor alert" mean help needed? If so I'm happy to help - take it off your plate to help reach 0.1 (for #358).

How was macro-compat insufficient? FWIW its goal is to remove differences, but as the cases appears so anything missing just needs to be added (I did a whole bunch of them to migrate shapeless).

Contributor

dwijnand commented Apr 6, 2016

Does "Contributor alert" mean help needed? If so I'm happy to help - take it off your plate to help reach 0.1 (for #358).

How was macro-compat insufficient? FWIW its goal is to remove differences, but as the cases appears so anything missing just needs to be added (I did a whole bunch of them to migrate shapeless).

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Apr 6, 2016

Member

I had two problems during my short porting experiment the other day:

  1. Due to some reason, I witnessed @bundle annotations not being enough for some of the macros that I had. Even with @bundle present, scalac kept on telling me things like object FooMacros not found - but not on all macros, just on some of them.
  2. In some places, I'm using Universe APIs directly to share code between compile-time and runtime reflection utilities, e.g. see https://github.com/xeno-by/scalameta/blob/d8a74ba169309ace1f0dc8bc7afeaa3fd930bc91/foundation/src/main/scala/org/scalameta/adt/Reflection.scala. If I understand correctly, macro-compat isn't very useful in such situations.

Thanks for the offer to help! Let me make a more serious attempt this week (Denys asked me to try and get the port through for his Saturday's talk at http://www.scalaua.com/). If I'm unable to make significant progress, I'd appreciate your help. I'll post a comment here with a status update.

Member

xeno-by commented Apr 6, 2016

I had two problems during my short porting experiment the other day:

  1. Due to some reason, I witnessed @bundle annotations not being enough for some of the macros that I had. Even with @bundle present, scalac kept on telling me things like object FooMacros not found - but not on all macros, just on some of them.
  2. In some places, I'm using Universe APIs directly to share code between compile-time and runtime reflection utilities, e.g. see https://github.com/xeno-by/scalameta/blob/d8a74ba169309ace1f0dc8bc7afeaa3fd930bc91/foundation/src/main/scala/org/scalameta/adt/Reflection.scala. If I understand correctly, macro-compat isn't very useful in such situations.

Thanks for the offer to help! Let me make a more serious attempt this week (Denys asked me to try and get the port through for his Saturday's talk at http://www.scalaua.com/). If I'm unable to make significant progress, I'd appreciate your help. I'll post a comment here with a status update.

xeno-by added a commit to xeno-by/scalameta that referenced this issue Apr 11, 2016

preparation for #295
Refactors some macro implementations to simplify their upcoming migration
to Scala 2.10. Found a lot of cruft, especially into the ast/branch/root
family of annotations.

xeno-by added a commit that referenced this issue Apr 11, 2016

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Apr 11, 2016

Member

@dwijnand It looks like I'll need your help. I had to tend to something else last week, so I didn't have time to migrate stuff to 2.10 myself. Please take a look if you still have time.

Here's a high-level overview of how we use macros in scala.meta (macros are grouped by projects where their implementations, not their definitions, are defined):

  1. Most macros are defined in foundation - the project that serves a role similar to projects called macros in other libraries. foundation is subdivided into a public part (org.scalameta.*), which features generally useful functionality, and a private part (scala.meta.internal.*), which has macros that are very heavily tuned to particulars of certain subprojects of scala.meta.
  2. prettyprinters: a couple really simple macros that provide smoother UI to prettyprinting.
  3. quasiquotes: quite involved logic that handles everything from parsing to reifying for quasiquotes.
  4. tql: tricky macros that smooth the rough edges of a very involved tree manipulation DSL.
  5. trees: a simple macro that figures out whether given tree types can be compared for equality.

I expect the most hairy part of migration to involve the @ast macro annotation that we use to generate boilerplate for our ASTs. Today I did some refactoring to a bunch of macro implementations to make them easier to understand, but @ast and its friends in scala.meta.internal.ast have so much cruft that it'd take me a week or more to get them into shape. Hopefully, this complexity won't lead into much complexity for backporting.

Tomorrow, I'll most likely cut tql out of scala.meta, so please don't look into scala.meta.internal.tql and scala.meta.tql just yet. Those macros are quite involved and most likely they won't live much longer.

Member

xeno-by commented Apr 11, 2016

@dwijnand It looks like I'll need your help. I had to tend to something else last week, so I didn't have time to migrate stuff to 2.10 myself. Please take a look if you still have time.

Here's a high-level overview of how we use macros in scala.meta (macros are grouped by projects where their implementations, not their definitions, are defined):

  1. Most macros are defined in foundation - the project that serves a role similar to projects called macros in other libraries. foundation is subdivided into a public part (org.scalameta.*), which features generally useful functionality, and a private part (scala.meta.internal.*), which has macros that are very heavily tuned to particulars of certain subprojects of scala.meta.
  2. prettyprinters: a couple really simple macros that provide smoother UI to prettyprinting.
  3. quasiquotes: quite involved logic that handles everything from parsing to reifying for quasiquotes.
  4. tql: tricky macros that smooth the rough edges of a very involved tree manipulation DSL.
  5. trees: a simple macro that figures out whether given tree types can be compared for equality.

I expect the most hairy part of migration to involve the @ast macro annotation that we use to generate boilerplate for our ASTs. Today I did some refactoring to a bunch of macro implementations to make them easier to understand, but @ast and its friends in scala.meta.internal.ast have so much cruft that it'd take me a week or more to get them into shape. Hopefully, this complexity won't lead into much complexity for backporting.

Tomorrow, I'll most likely cut tql out of scala.meta, so please don't look into scala.meta.internal.tql and scala.meta.tql just yet. Those macros are quite involved and most likely they won't live much longer.

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Apr 16, 2016

Member

@dwijnand I've just merged a replacement for tql. It still has some macros, but those are much less involved.

Member

xeno-by commented Apr 16, 2016

@dwijnand I've just merged a replacement for tql. It still has some macros, but those are much less involved.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand May 16, 2016

Contributor

WIP master...dwijnand:add-support-for-scala-210

I'll pick this up again soon.

Contributor

dwijnand commented May 16, 2016

WIP master...dwijnand:add-support-for-scala-210

I'll pick this up again soon.

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@fommil

This comment has been minimized.

Show comment
Hide comment
@fommil

fommil May 22, 2016

I guess that would spell the end for ensime support of 2.10, but since we won't be using scala.meta for a while yet it might just mean that ensime 1.0 or 2.0 is the last to support 2.10. I only use 2.10 for sbt projects, so when my projects are migrated, I don't care about 2.10 anymore.

fommil commented May 22, 2016

I guess that would spell the end for ensime support of 2.10, but since we won't be using scala.meta for a while yet it might just mean that ensime 1.0 or 2.0 is the last to support 2.10. I only use 2.10 for sbt projects, so when my projects are migrated, I don't care about 2.10 anymore.

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by May 23, 2016

Member

It seems that I won't have time for this migration for quite a while, but maybe someone else will pick it up, so I won't be closing the issue.

@dwijnand Maybe you have ideas how we could simplify scala.meta to make migration easier? If it doesn't take much time, I could look into implementing such simplifications soon. Our use of macros is mostly internal, so we should have a lot of freedom in moving stuff around.

Member

xeno-by commented May 23, 2016

It seems that I won't have time for this migration for quite a while, but maybe someone else will pick it up, so I won't be closing the issue.

@dwijnand Maybe you have ideas how we could simplify scala.meta to make migration easier? If it doesn't take much time, I could look into implementing such simplifications soon. Our use of macros is mostly internal, so we should have a lot of freedom in moving stuff around.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand May 23, 2016

Contributor

I didn't spend much time exploring the scalameta sources so I don't really know what or where it can be simplified.

The only thing that I noted is there is insufficient hooks in macro-compat for cross-building, as macro-compat only works for macro bundles. It would be nice if it provided abstractions over the differences in Universe-based code, which scalameta has to share code between macros and reflection (IIUC). /cc @milessabin.

Contributor

dwijnand commented May 23, 2016

I didn't spend much time exploring the scalameta sources so I don't really know what or where it can be simplified.

The only thing that I noted is there is insufficient hooks in macro-compat for cross-building, as macro-compat only works for macro bundles. It would be nice if it provided abstractions over the differences in Universe-based code, which scalameta has to share code between macros and reflection (IIUC). /cc @milessabin.

@xeno-by xeno-by removed this from the 1.0 milestone May 25, 2016

@fommil fommil referenced this issue in ensime/ensime-server Jun 3, 2016

Closed

use scalafmt #1439

@cvogt

This comment has been minimized.

Show comment
Hide comment
@cvogt

cvogt Jun 3, 2016

-1 Let's focus efforts on the future present, not the future past. Sbt 1.0 is running on scala 2.11. By the time meta is getting serious adoption most people will have switched and if meta is just one more reason for people to stay up to date with technology - great.

cvogt commented Jun 3, 2016

-1 Let's focus efforts on the future present, not the future past. Sbt 1.0 is running on scala 2.11. By the time meta is getting serious adoption most people will have switched and if meta is just one more reason for people to stay up to date with technology - great.

@olafurpg

This comment has been minimized.

Show comment
Hide comment
@olafurpg

olafurpg Jun 3, 2016

Member

I would like to add that I think Scala.js support (#359) deserves a higher priority than this issue. I imagine the syntactic API is sufficient for many to implement cool applications such as browser extensions for proper syntax highlighting or (heuristic based) "jump to definition" links on Github. For SBT integration I suppose people expect to have the semantic API, which won't be available until later anyways.

Member

olafurpg commented Jun 3, 2016

I would like to add that I think Scala.js support (#359) deserves a higher priority than this issue. I imagine the syntactic API is sufficient for many to implement cool applications such as browser extensions for proper syntax highlighting or (heuristic based) "jump to definition" links on Github. For SBT integration I suppose people expect to have the semantic API, which won't be available until later anyways.

@fommil

This comment has been minimized.

Show comment
Hide comment
@fommil

fommil Jun 3, 2016

probably best to close this then? Clarifies that ENSIME 3.0 will have to drop scala 2.10 support.

fommil commented Jun 3, 2016

probably best to close this then? Clarifies that ENSIME 3.0 will have to drop scala 2.10 support.

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Jun 4, 2016

Member

Let's give this issue a bit more time. I have an idea how to implement it within a reasonable timeframe, and I'd like to check that idea first at some point before giving up.

Member

xeno-by commented Jun 4, 2016

Let's give this issue a bit more time. I have an idea how to implement it within a reasonable timeframe, and I'd like to check that idea first at some point before giving up.

@densh densh referenced this issue in scala-native/scala-native Jun 10, 2016

Closed

Better templating #135

0 of 2 tasks complete

olafurpg added a commit to olafurpg/scalameta that referenced this issue Oct 12, 2016

preparation for #295
Refactors some macro implementations to simplify their upcoming migration
to Scala 2.10. Found a lot of cruft, especially into the ast/branch/root
family of annotations.

@olafurpg olafurpg referenced this issue in scalameta/scalafmt Nov 19, 2016

Closed

SBT plugin is looking for a new maintainer #597

@barkhorn

This comment has been minimized.

Show comment
Hide comment
@barkhorn

barkhorn Jan 22, 2017

For the forseeable future, I am stuck with Scala 2.10, due to our Spark cluster being held back from upgrading to Spark 2+.
So it would be great to have 2.10 support in meta, to be able to rewrite parts of ScalaMock for 2.10, 2.11, 2.12, +JS

For the forseeable future, I am stuck with Scala 2.10, due to our Spark cluster being held back from upgrading to Spark 2+.
So it would be great to have 2.10 support in meta, to be able to rewrite parts of ScalaMock for 2.10, 2.11, 2.12, +JS

@barkhorn barkhorn referenced this issue in paulbutcher/ScalaMock Jan 22, 2017

Open

investigate effort to move to scala.meta #145

@dwijnand dwijnand referenced this issue in scala/scala-dev Feb 27, 2017

Open

compiler-compat #316

@DavidDudson

This comment has been minimized.

Show comment
Hide comment
@DavidDudson

DavidDudson Feb 28, 2017

Member

It was just mentioned in the scalafix channel that 2.10 support would be welcomed.

I think scalafix is definitely a factor here. Since most libraries cross compiles 2.10/2.11 and a lot of people are indeed stuck on 2.10 for a variety of reason. If scalafix could help migrate old codebases from 2.10 to 2.12 then I'm sure a large chunk of the community would appreciate it.

In saying that we definately have more important priorities. So I'm all for keeping this open.

Member

DavidDudson commented Feb 28, 2017

It was just mentioned in the scalafix channel that 2.10 support would be welcomed.

I think scalafix is definitely a factor here. Since most libraries cross compiles 2.10/2.11 and a lot of people are indeed stuck on 2.10 for a variety of reason. If scalafix could help migrate old codebases from 2.10 to 2.12 then I'm sure a large chunk of the community would appreciate it.

In saying that we definately have more important priorities. So I'm all for keeping this open.

@milessabin

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Mar 1, 2017

@xeno-by at the top of this thread you said "given that we don't even have a working scalahost for 2.11" ... is this still the case?

@xeno-by at the top of this thread you said "given that we don't even have a working scalahost for 2.11" ... is this still the case?

@DavidDudson

This comment has been minimized.

Show comment
Hide comment
@DavidDudson

DavidDudson Mar 1, 2017

Member

@milessabin There are very few issues with scalahost. It works with pretty well with scala 2.11 and 2.12
https://github.com/scalameta/scalameta/labels/Scalahost

The key list of remaining things to be ported are in the below ticket:
#619

Most of these are rarely used. If anyone encounters something that's missing that they need we tend to implement it pretty much straight away.

Scalahost has also been moved from being embedded in paradise to being a subproject of scalameta.

Member

DavidDudson commented Mar 1, 2017

@milessabin There are very few issues with scalahost. It works with pretty well with scala 2.11 and 2.12
https://github.com/scalameta/scalameta/labels/Scalahost

The key list of remaining things to be ported are in the below ticket:
#619

Most of these are rarely used. If anyone encounters something that's missing that they need we tend to implement it pretty much straight away.

Scalahost has also been moved from being embedded in paradise to being a subproject of scalameta.

@milessabin

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Mar 1, 2017

Is scalahost the only thing which needs to be ported to 2.10?

Is scalahost the only thing which needs to be ported to 2.10?

@DavidDudson

This comment has been minimized.

Show comment
Hide comment
@DavidDudson

DavidDudson Mar 1, 2017

Member

To be honest, I don't have the full answer. I presume @xeno-by will.

I know that we cannot run scalameta in 2.10. All the macros would have to be backported (Probably using macro compat). And possibly other things??? Scalahost is only necessary for semantic rewrites, syntactic rewrites can happen without it. Also scala.meta annotation macros depend on scalahost.

In regards to syntactic rewrites, if you run scalameta in 2.11/2.12 and use the 2.10 dialect, I see no reason why it wouldn't work (I personally have not tested this, nor do we have a large test suite to verify this like we do for 2.11).

Member

DavidDudson commented Mar 1, 2017

To be honest, I don't have the full answer. I presume @xeno-by will.

I know that we cannot run scalameta in 2.10. All the macros would have to be backported (Probably using macro compat). And possibly other things??? Scalahost is only necessary for semantic rewrites, syntactic rewrites can happen without it. Also scala.meta annotation macros depend on scalahost.

In regards to syntactic rewrites, if you run scalameta in 2.11/2.12 and use the 2.10 dialect, I see no reason why it wouldn't work (I personally have not tested this, nor do we have a large test suite to verify this like we do for 2.11).

@olafurpg

This comment has been minimized.

Show comment
Hide comment
@olafurpg

olafurpg Mar 1, 2017

Member

@milessabin scalahost that came in 1.6 is a new module and doesn't define any macros. The scalahost mentioned in the issue description references an older scalahost design, which is no longer relevant.

I believe the main up-to-date challenges to porting to 2.10 are listed in #295 (comment) In particular, the @ast/@root/@leaf/@branch macro annotations are used in the Tree ADT, see here https://github.com/scalameta/scalameta/blob/master/scalameta/trees/src/main/scala/scala/meta/Trees.scala tql is no longer a module

Member

olafurpg commented Mar 1, 2017

@milessabin scalahost that came in 1.6 is a new module and doesn't define any macros. The scalahost mentioned in the issue description references an older scalahost design, which is no longer relevant.

I believe the main up-to-date challenges to porting to 2.10 are listed in #295 (comment) In particular, the @ast/@root/@leaf/@branch macro annotations are used in the Tree ADT, see here https://github.com/scalameta/scalameta/blob/master/scalameta/trees/src/main/scala/scala/meta/Trees.scala tql is no longer a module

@milessabin

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Mar 1, 2017

@olafurpg I was looking at ScalahostAnalyzer which seems to be the main version-variant source in this repo ... am I looking in the wrong place?

@olafurpg I was looking at ScalahostAnalyzer which seems to be the main version-variant source in this repo ... am I looking in the wrong place?

@olafurpg

This comment has been minimized.

Show comment
Hide comment
@olafurpg

olafurpg Mar 1, 2017

Member

@milessabin I think the best place to look is here https://github.com/scalameta/scalameta/tree/master/scalameta/common/src/main/scala/scala/meta/internal/ast

I don't think scalahost is main the blocker for 2.10 support.

As for the sbt plugin use-case, I use classloading to run scala.meta in the scalafmt, scalafix and scalahost sbt plugins. It's not perfect, but it works pretty good as long as you use coursier instead of the built-in sbt update task.

Member

olafurpg commented Mar 1, 2017

@milessabin I think the best place to look is here https://github.com/scalameta/scalameta/tree/master/scalameta/common/src/main/scala/scala/meta/internal/ast

I don't think scalahost is main the blocker for 2.10 support.

As for the sbt plugin use-case, I use classloading to run scala.meta in the scalafmt, scalafix and scalahost sbt plugins. It's not perfect, but it works pretty good as long as you use coursier instead of the built-in sbt update task.

@fommil

This comment has been minimized.

Show comment
Hide comment
@fommil

fommil Mar 1, 2017

@olafurpg I want to hack on a interactiveCompile task at scalasphere on Saturday, can I grab you for a bit to show me how you did this?

fommil commented Mar 1, 2017

@olafurpg I want to hack on a interactiveCompile task at scalasphere on Saturday, can I grab you for a bit to show me how you did this?

@olafurpg

This comment has been minimized.

Show comment
Hide comment
@olafurpg

olafurpg Mar 1, 2017

Member

@fommil Do you mean classload with coursier? Sure thing 😄 there's not much to it really, see here.

As for this issue, I think it's reasonable to expect OSS libraries to support the two latest versions of Scala (2.11 + 2.12). I think it's unfair to expect library maintainers to bend head over heels to support 2.10 when the maintainers themselves (+supporters) have limited use for it.

Member

olafurpg commented Mar 1, 2017

@fommil Do you mean classload with coursier? Sure thing 😄 there's not much to it really, see here.

As for this issue, I think it's reasonable to expect OSS libraries to support the two latest versions of Scala (2.11 + 2.12). I think it's unfair to expect library maintainers to bend head over heels to support 2.10 when the maintainers themselves (+supporters) have limited use for it.

@fommil

This comment has been minimized.

Show comment
Hide comment
@fommil

fommil Mar 1, 2017

I really wish we could drop 2.10... the only thing holding me back is sbt.

Otherwise, I think it's fair to expect 2.10 (and arguably 2.11) support only on a commercial basis.

What we need to do is to pester Eugene constantly at scalasphere until he agrees to a 0.14 cut of sbt which is 0.13 built on 2.12 😄

fommil commented Mar 1, 2017

I really wish we could drop 2.10... the only thing holding me back is sbt.

Otherwise, I think it's fair to expect 2.10 (and arguably 2.11) support only on a commercial basis.

What we need to do is to pester Eugene constantly at scalasphere until he agrees to a 0.14 cut of sbt which is 0.13 built on 2.12 😄

@cvogt

This comment has been minimized.

Show comment
Hide comment
@cvogt

cvogt Mar 2, 2017

One way to look at it: Do we rather want 2.10 support or faster progress on the semantic api? I'd personally choose the latter :).

cvogt commented Mar 2, 2017

One way to look at it: Do we rather want 2.10 support or faster progress on the semantic api? I'd personally choose the latter :).

@milessabin

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Mar 2, 2017

I think that 2.10 will be with us for a long time, so the absence of support for modern tooling on 2.10 will hold everyone back. This has pretty clearly been the case wrt SBT plugins, and I expect it will be more than a year before even a bare majority of Scala users will be on an SBT version that's > 2.10.x.

I think that 2.10 will be with us for a long time, so the absence of support for modern tooling on 2.10 will hold everyone back. This has pretty clearly been the case wrt SBT plugins, and I expect it will be more than a year before even a bare majority of Scala users will be on an SBT version that's > 2.10.x.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Mar 2, 2017

Contributor

Again, there are ways to use scalameta today in sbt even if sbt is 2.10.

I'm happy to use scala.meta not supporting 2.10 to motivate and push people to upgrade away from 2.10, including sbt, as well as motivate and push people to upgrade to sbt 0.14/1.0.

Contributor

dwijnand commented Mar 2, 2017

Again, there are ways to use scalameta today in sbt even if sbt is 2.10.

I'm happy to use scala.meta not supporting 2.10 to motivate and push people to upgrade away from 2.10, including sbt, as well as motivate and push people to upgrade to sbt 0.14/1.0.

@barkhorn

This comment has been minimized.

Show comment
Hide comment
@barkhorn

barkhorn Mar 2, 2017

For us it is the dependency on bundled versions of Spark that forces us to stick with 2.10. Can't see that being resolved in at least this year, and there are probably other users of the Cloudera stack that are in a similar position.

barkhorn commented Mar 2, 2017

For us it is the dependency on bundled versions of Spark that forces us to stick with 2.10. Can't see that being resolved in at least this year, and there are probably other users of the Cloudera stack that are in a similar position.

@DavidDudson

This comment has been minimized.

Show comment
Hide comment
@DavidDudson

DavidDudson Apr 10, 2017

Member

#735 will help with this, but we will still need to wait for def macros. If we can build all of the macros with meta, we may be a step closer.

Member

DavidDudson commented Apr 10, 2017

#735 will help with this, but we will still need to wait for def macros. If we can build all of the macros with meta, we may be a step closer.

@xeno-by xeno-by referenced this issue in scalameta/scalafmt May 8, 2017

Closed

please publish for sbt 0.13 #923

@xeno-by xeno-by self-assigned this May 20, 2017

@xeno-by xeno-by added this to the v2.0.0 milestone May 20, 2017

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Sep 1, 2017

Member

Crosscompiling to Scala 2.10 and keeping ourselves crosscompiled is a lot of work that will significantly distract us from our progress on semantic API. With sbt 1.0 released, I can no longer justify this work, so I'll be closing this issue.

Note that Scalameta always supported syntactic analysis of Scala 2.10 codebases. Recently, @olafurpg also added some support for semantic analysis via https://github.com/scalameta/semanticdb-sbt.

Member

xeno-by commented Sep 1, 2017

Crosscompiling to Scala 2.10 and keeping ourselves crosscompiled is a lot of work that will significantly distract us from our progress on semantic API. With sbt 1.0 released, I can no longer justify this work, so I'll be closing this issue.

Note that Scalameta always supported syntactic analysis of Scala 2.10 codebases. Recently, @olafurpg also added some support for semantic analysis via https://github.com/scalameta/semanticdb-sbt.

@xeno-by xeno-by closed this Sep 1, 2017

@olafurpg

This comment has been minimized.

Show comment
Hide comment
@olafurpg

olafurpg Sep 1, 2017

Member

To elaborate, it should be possible to use semanticdb-sbt to run semantic scalafix rewrites on 2.10 codebases. This is not officially supported, but the installation setup is identical as with semanticdb-scalac (2.11/2.12).

Member

olafurpg commented Sep 1, 2017

To elaborate, it should be possible to use semanticdb-sbt to run semantic scalafix rewrites on 2.10 codebases. This is not officially supported, but the installation setup is identical as with semanticdb-scalac (2.11/2.12).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment