sbt/sbt

A relaxed chat room about sbt (the interactive build tool). Also good for sbt help: Stack Overflow, or Lightbend subscription. https://www.scala-sbt.org/support.html has advice on where to go.

ykycxzsv

@ykycxzsv

ok. i think i'll try to convert it to a task, but problem is the implementation has to call other existing commands. i understand that i can read state.value and pass to the command's state parameter, but i should also update state based on result of the command. i tried state := command(state.value), but now the task doesn't do anything!

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.

Michael Pollmeier

@mpollmeier

there we go, thanks again!
https://stackoverflow.com/questions/44720389/sbt-programmatically-resolve-task-scope/44720390#44720390

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

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

Where communities thrive

People

Repo info

Activity