Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 22 2015 11:10
    japgolly commented #2066
  • Jun 22 2015 08:25
    keepscoding commented #2044
  • Jun 21 2015 03:24
    xerial commented #157
  • Jun 21 2015 00:10
    eed3si9n unlabeled #2057
  • Jun 21 2015 00:10

    eed3si9n on 0.13

    Adds bundledLauncherProj to all… Remove launcher tests Add unit tests to Travis and 3 more (compare)

  • Jun 21 2015 00:10
    eed3si9n closed #2057
  • Jun 21 2015 00:10

    eed3si9n on fixbuild

    (compare)

  • Jun 20 2015 18:42
    eed3si9n synchronize #2057
  • Jun 20 2015 18:42

    eed3si9n on fixbuild

    Fix typo (compare)

  • Jun 20 2015 18:23

    eed3si9n on fixbuild

    Adds bundledLauncherProj to all… Remove launcher tests Add unit tests to Travis and 1 more (compare)

  • Jun 20 2015 18:23
    eed3si9n synchronize #2057
  • Jun 20 2015 14:59

    eed3si9n on scalaversionbump

    (compare)

  • Jun 20 2015 14:59

    eed3si9n on 0.13

    Bumping up Scala version to 2.1… Try to keep bincompat Fixes #1666 and 1 more (compare)

  • Jun 20 2015 14:59
    eed3si9n unlabeled #2068
  • Jun 20 2015 14:59
    eed3si9n closed #2068
  • Jun 20 2015 14:59
    eed3si9n closed #1666
  • Jun 20 2015 14:57
    eed3si9n commented #2068
  • Jun 20 2015 12:55
    dwijnand commented #2068
  • Jun 20 2015 04:51
    eed3si9n synchronize #2068
  • Jun 20 2015 04:51

    eed3si9n on scalaversionbump

    Fixes #1666 (compare)

Dale Wijnand
@dwijnand
if you don't opt-out it comes with a big annoying message telling you exactly everything it's undone because you're a (dirty) macro user.
@shajra yeah +/++ create session settings, that are used to re-evaluate and re-define all the setting values. If you can share what you're seeing we might be able to help you out.
And your sbt-doge question, did you mean in your project or are you talking about whether sbt-doge should be changed?
Ghost
@ghost~540393fe163965c9bc2018ce
@dwijnand hmm, maybe it's broken for scala.meta
or, rather, doesn't support scala.meta
I was making changes to the freestyle @free macro, and nothing downstream was getting recompiled
I'd have been happy with everything being marked dirty
Dale Wijnand
@dwijnand
mmm could be
Sukant Hajra
@shajra
@dwijnand no, I mean enabling it for all projects internally. It seems to work fine.
Dale Wijnand
@dwijnand
yeah it's fine
Dale Wijnand
@dwijnand
:+1:
Jose C
@jmcardon
As we spoke I opened the gates to discussion on this hopefully reasonably
I sincerely believe this would lead to a positive change long term
less docs to maintain
and more convergence from the entire community
Dale Wijnand
@dwijnand
You propose deprecating a style that I don't see too common in the (OSS) wild, so provided we cater for those that are using that style (deprecation warnings, opt-in/opt-out, auto-rewrite) I think it's very achievable.
Jose C
@jmcardon
I do believe play framework is using the recursive sbt in folders style as an example
Jorge
@jvican
@jmcardon I don't understand what you're proposing
hasn't Build.scala disappeared in sbt 1.0?
Jose C
@jmcardon
@jvican removing recursive build.sbt definitions
wherein you have to recurse into folders
Jorge
@jvican
No way, that's impossible
First, that's not a different style, it's a feature
Second, that's the foundation for the way plugins work
Jose C
@jmcardon
I mean... different build.sbt files in different folders
not so much the plugins
Jorge
@jvican
Ah, so then I wouldn't call it recursive build definition
Jose C
@jmcardon
my bad on the wording then
This is partly what causes a rift so hard when having any discussions as to how to do things in sbt. Essentially supporting many different ways of doing the same thing
Jorge
@jvican
No worries, that was a misunderstanding
So I think that's very contentious, because what do you do with multiple .sbt files in a directory?
Dale Wijnand
@dwijnand
You keep those, imo.
Being able to define a gitignored local.sbt is useful.
Jorge
@jvican
Yes, you have to... every build in the wild uses differnt sbt files in project
Dale Wijnand
@dwijnand
yeah that too
Jose C
@jmcardon
I think different .sbt files in a top level project is fine. Not so much in different ones in many different directories adding to the hackery that needs to be done for that to work
eugene yokota
@eed3si9n
I'd love to see this topic captured as a GitHub issue
Jose C
@jmcardon
I thought it was a tad broad for an issue
Jorge
@jvican
I think Scala Contributors is fine for this
It will get more outreach
Jose C
@jmcardon
I opted for discussion first so the community could think about what exactly constitutes an issue in this
eugene yokota
@eed3si9n
I am guessing that the original idea was that each subdir could exist as a build on its own
but it quickly breaks down with plugins
Jorge
@jvican
@jmcardon so the hackery that needs to be done for that to work won't disappear because it's required for recursive builds to work
Dale Wijnand
@dwijnand
and build.properties
Jorge
@jvican
but i agree with the sentiment of removing multiple sbt files in recursive dirs that are not project
Dale Wijnand
@dwijnand
also at the beginning of sbt files you couldn't define projects in them, so you couldn't have single top-level build.sbt style
Jose C
@jmcardon
I don't mean the actual procedure in the tool, just the style
This topic is rather broad so excuse my difficulty in nailing the wording just right