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
yeah you can't call commands from tasks
as a workaround to that feature missing you could take the project name as a first argument
ykycxzsv
@ykycxzsv
i don't need the project name, i need to fit in a framework which attempts to do "sbt project/mycommand". since commands don't support that syntax, i have to use a task, but since tasks can't call commands, i'm screwed. guess it's time for some ugly kludge
Ghost
@ghost~540393fe163965c9bc2018ce
if it's your command, you could take the project name as an input
but then you'd want to rewrite your Command as a Task anyway...
ykycxzsv
@ykycxzsv
like i said, i DON'T need the project name. and i can't rewrite my command to a task if a task can't call other commands
Dale Wijnand
@dwijnand
You need to run the command in a specific project, though, right?
Michael Pollmeier
@mpollmeier

How can I refer to a scoped key programmatically? I.e. what is the programmatic equivalent of e.g. scalafmt::test?

Context: neo-sbt-scalafmt defines a TaskKey scalafmt that formats your sources, but it also defines a scope called test (https://github.com/lucidsoftware/neo-sbt-scalafmt/blob/master/sbt-scalafmt/src/main/scala/com/lucidchart/sbt/scalafmt/ScalafmtCorePlugin.scala#L143) that only checks if the sources are in line with the expected format. Depending on a SettingKey the TaskKey scalaFmt is invoked before compile. I want to introduce a new SettingKey that invokes scalafmt::test instead. The below compiles, but always runs scalafmt, not scalafmt::test.

    if (scalafmtOnCompile.value) scalafmt in resolvedScoped.value.scope
    else if (scalafmtTestOnCompile.value) (test in scalafmt) in resolvedScoped.value.scope

https://github.com/lucidsoftware/neo-sbt-scalafmt/blob/master/sbt-scalafmt/src/main/scala/com/lucidchart/sbt/scalafmt/ScalafmtCorePlugin.scala#L170

Dale Wijnand
@dwijnand
Try test in (resolvedScoped.value.scope in scalafmt)
which basically means: "take the existing scope, but make it in scalafmt task scope, that's the scope of test that I want to use"
Michael Pollmeier
@mpollmeier
hmm, that doesn't compile, because scalafmt is a TaskKey, and in takes one of AttributeKey, ConfigKey or Reference. Not sure what those are, will have a look if it's possible to convert a TaskKey into one of them..
Dale Wijnand
@dwijnand
test in (resolvedScoped.value.scope in scalafmt.key) should compile
Michael Pollmeier
@mpollmeier
yes, just found that as well. it compiles, but it still acts like scalafmt, not scalafmt::test. Can you have a quick look at this line and tell me if my understanding is correct, that it's a scoped key? This is what I want to refer to:
https://github.com/lucidsoftware/neo-sbt-scalafmt/blob/master/sbt-scalafmt/src/main/scala/com/lucidchart/sbt/scalafmt/ScalafmtCorePlugin.scala#L143
Dale Wijnand
@dwijnand
so it's defined unscoped, then it passed through inTask, which scopes it
Michael Pollmeier
@mpollmeier
so, it should work right? for context, here's my commit: mpollmeier/neo-sbt-scalafmt@4a113d7
I'm using that in a project where inspect scalafmtTestOnCompile tells me [info] Setting: Boolean = true
but when I run compile it runs scalafmt, not scalafmt::test
should I open a stackoverflow question instead?
Dale Wijnand
@dwijnand
just to sanity check: scalafmtOnCompile is false, right?
Michael Pollmeier
@mpollmeier
Correct
Michael Pollmeier
@mpollmeier
actually, no! I just inspected the value of scalafmtOnCompile and it was set to true in a different file. sorry!
so, yes, your suggested test in (resolvedScoped.value.scope in scalafmt.key) does the job. thank you!
would you like me to add this to the docs, or create a stackoverflow question with answer?
I'll wrap up a PR for neo-sbt-scalafmt shortly
Dale Wijnand
@dwijnand
resolvedScoped is a pretty advanced topic. But a stackoverflow question and answer can't hurt, can it.
s3ni0r
@s3ni0r

Hi everyone, i have a custom resolver in my build.sbt file that's not challenged when resolving dependencies, these are my revolvers

resolvers ++= Seq(
      Resolver.sonatypeRepo("snapshots")
      ,Resolver.sonatypeRepo("releases")
      ,Resolver.typesafeRepo("releases")
      ,"spray repo" at "http://repo.spray.io"
      ,"SpinGo OSS" at "http://spingo-oss.s3.amazonaws.com/repositories/releases"
    )

and this is the warning i get :

[info] Resolving com.spingo#op-rabbit-core_2.11;1.2.1 ...
[warn]     module not found: com.spingo#op-rabbit-core_2.11;1.2.1
[warn] ==== local: tried
[warn]   /root/.ivy2/local/com.spingo/op-rabbit-core_2.11/1.2.1/ivys/ivy.xml
[warn] ==== local-preloaded-ivy: tried
[warn]   /root/.sbt/preloaded/com.spingo/op-rabbit-core_2.11/1.2.1/ivys/ivy.xml
[warn] ==== local-preloaded: tried
[warn]   file:////root/.sbt/preloaded/com/spingo/op-rabbit-core_2.11/1.2.1/op-rabbit-core_2.11-1.2.1.pom
[warn] ==== public: tried
[warn]   https://repo1.maven.org/maven2/com/spingo/op-rabbit-core_2.11/1.2.1/op-rabbit-core_2.11-1.2.1.pom

i tried both sbt 13.8 and 13.15 and got the same result, do you guys have any idea about this? thanks for your help

OlegYch
@OlegYch
that probably means your config is not actually applied
eg the resolvers are applied to different project
s3ni0r
@s3ni0r
yeah i have 3 modules
and the resolvers above are included in the modules that uses the needed dependency
it suddenly stopped working
s3ni0r
@s3ni0r
Problem solved it was a module dependency issue, thanks everyone :)
Jose C
@jmcardon
@dwijnand a few days later it seems most people are on board sort of
with the style proposal
:D
Dale Wijnand
@dwijnand
Yep! :)
Ryan Williams
@ryan-williams

are multi-module projects always configured from the root?

I want to have a multi-module SBT project where the SBT modules are also git submodules with their own build.sbt's, that can be built as stand-alone projects when cloned by themselves / separately from the any multi-module context.

The root project build configs would describe tasks related to interactions between the modules: rebuilding modules that depend on other modules, etc., but without repeating module-specific configurations that already exist in each module's build configs.

Can a root project play nicely with modules' existing SBT configs?

OlegYch
@OlegYch
no, projects can only be configured at the root
Jose C
@jmcardon
@ryan-williams like you want each subproject in it's own repo?
Ryan Williams
@ryan-williams
@jmcardon correct; each subproject is its own repo, but I also develop them together in an umbrella repo that contains each one as a submodule: https://github.com/hammerlab/pageant and it would be nice to be able to add tooling/config that pertains to multiple modules, or how they relate to one another, at that level
Ryan Williams
@ryan-williams

some larger context is that i feel that with appropriate build- and VCS- tooling a person should be able to have the best of both of the {mono,poly}-repo worlds: upgrading a bunch of inter-connected components in lockstep when that is desired (e.g. a single commit to an umbrella repo that upgrades the submodule SHAs of its submodule-repos) while still letting the component projects exist and be developed/forked in a standalone way.

git submodules basically do exactly what is needed here on the VCS front, and i'm trying to figure out whether I can get SBT to handle it as well. it seems philosophically aligned with SBT's whole "recursive project definitions" design, but afaict ppl don't use it this way and current SBT may not make this feasible

Jose C
@jmcardon
ah... ironically I made a proposal to get rid of those sort of definitions
because of the complications in style convergence within sbt
OlegYch
@OlegYch
you could load projects from another build with ProjectRef, but there are some complications
eg only one set of plugins per build
Jose C
@jmcardon
These complications is part of the proposal... Like jumping between projects doing this results in a lot of uglyness
Ryan Williams
@ryan-williams
@jmcardon yea that makes sense, i think what i want here is pretty different from that though, maybe i shouldn't have mentioned it. i just want my build configs, like my libraries, to do specific things and outsource/depend on other builds/libraries for their things. having to configure all modules' builds in the top level of a multi-module repo is a smell according to this view: it's only appropriate to handle cross-module concerns at that level, modules themselves should be cloneable/buildable in isolation from other things that they might be grouped with in higher-level contexts
@OlegYch very interesting, yea that's kind of what i'm interested in finding out; it doesn't seem like people are doing what i'm imagining today and i don't expect that it has accidentally been supported all this time without ppl wanting it / using it that way
Jose C
@jmcardon
No no definitely do mention it
I think any pov with reasonable explanation is valid and beneficial to discussion
OlegYch
@OlegYch
fwiw i do it every day, but like i said it's not exactly reliable