bloop
bloop copied to clipboard
scalacenter
Support multi-module projects in buildpress
So far I’ve only added a direct project’s setting detection, but I think we need to support multi-module ones as well (ie if I run buildpress on bloop itself, it should detect changes in any module’s sbt settings). Not sure it’s possible w/o hooking deeper into sbt itself rather than just traversing directories. @jvican I would appreciate your input here assuming this makes sense to you.
cross-linking with #948 since I'm hoping to build on top of that.
By multi-module projects, are you referring here to ProjectRefs?
I'm totally fine not support project references. In my opinion, they lack a lot of polishing and their design/semantics are poorly specified. Yes, I use them, but I know I'm a power user working on a complicated project, so I'm fine dealing with build press not correctly supporting these :smile:
Yes, ProjectRefs. I know for a fact that some users are organizing their monorepos this way, ie toplevel module is just an aggregate of all modules which is serving infrastructure purposes like code coverage, integration tests etc, so they would find it useful since those are normally running as a part of CI processes. I added this as a separate issue because src-based plugins are ProjectRefs in meta-build, so if I find a nice and efficient way to support reading them, maybe we’ll get this for free.
It's true you can feed two birds with one scone.
Whenever you add a ProjectRef, a BuildRef pointing to the workspace base directory that defined that ProjectRef is added to the sbt internal graph/data structures. You could extract those BuildRefs and then run the hasher on top of those directories.
I don't remember right now the sbt APIs to extract such data (maybe BuildData or something like that, available by browsing the State APIs), but it's definitely possible. Feel free to play with these APIs in sbt-bloop, find the info, and whenever you have it we can decide how we can persist this data and make it accessible to buildpress.
I won't be really responsive for the next week and a half, so if you have questions ask them here and I'll try to get back to you whenever I find the time :smile:
Hey @jvican! Yes, hopefully soon. I got stuck between changing jobs and trying to do my own project, going to make some free time in the next couple of weeks. Let me get back into the problem first. Also, if you could have some time for call to sync on this, I would appreciate that very much.
Actually @jvican looks like I'm having too much on my plate right now, not sure I will be able to pay proper attention to this in the next month or so, so if there is anyone who wants to jump on this, they are welcome to. Sorry for the delay and/or inconvenience.
Hey @tkroman, I'm not that much interested in ProjectRefs but I do intend to be using buildpress soon to power some of our upcoming GitHub CI integrations and it'd be nice if you could quickly look at https://github.com/scalacenter/bloop/issues/948 and implement detection for source sbt plugins, it would unblock some interesting work and allow me to move forward quicker in the next few days.
Apparently this issue over at Metals never actually happened in Bloop?
Not the end of the world manually defining:
bloopAggregateSourceDependencies in Global := true
but would be nice to get ProjectRef support out of the box to clue in VS Code et al...
Apparently this issue over at Metals never actually happened in Bloop?
Not the end of the world manually defining:
bloopAggregateSourceDependencies in Global := truebut would be nice to get
ProjectRefsupport out of the box to clue in VS Code et al...
I actually haven't realized there is a separate option for that, but this seems to be true by default. If it doesn't work for a project, we should investigate.
To be clear, without the referenced setting sbt compiles just fine; it's VS Code/Metals/Bloop that doesn't recognize dependent git ProjectRef sources.
Also, Scala 3 RC1.
@godenji does it work with the setting? Do you have an example project maybe somewhere?
Yes, it works fine when I manually define the setting in my build.sbt; it's when I omit the setting that VS Code no longer recognizes git ProjectRef dependent sources.