Support generating {sbt,mill,gradle,Maven} builds

[jvican]

Imagine I was to use seed to teach Scala to beginners. I'd pick seed because it's so simple that I can explain how to declare a module and add a dependency in less than a paragraph. It imposes almost no overhead when teaching Scala to a crowd of developers inexperienced with the Scala build tool ecosystem and allows them to focus on what's important: learning the language.

However, a big drawback of doing this is that they would have learned to use a build tool that's perhaps really simple for future use cases and doesn't have major adoption in the community. I believe this is an important point.

To address that concern, I suggest seed can use generate valid build files out of its build schema. Given its simplicity, seeds format is a subset of the project settings in all the other build tools and making that generation is relatively straight-forward.

I'd suggest supporting sbt and mill at the beginning and then adding support for Gradle/Maven if there's demand. The great thing about this is that people can get started with seed but if they need unsupported features such as packaging/releasing they can generate a valid sbt/mill build out of it and continue with their lives.

[tindzk]

I thought about this too. A problem is that Seed modules do not map well onto sbt. The resulting build file will not be idiomatic and use unmanagedSourceDirectories for source paths, -Xplugin for Scala.js etc. I am also uncertain how useful the generated build will be.

The following use cases come to my mind:

• Publishing libraries: This is the main reason I still use sbt for my libraries, though proper publishing support is planned for a future version of Seed
• Play support: We currently require some boilerplate code for Twirl and route generation which makes it hard to set up a Play project
• Regression testing for Scala.js/Scala Native: Bloop hardcodes the linker version, so comparing the performance or output of different versions is not possible
• Running Scala Native tests: I did not get around implementing it yet in Bloop, but it should not be too much work

We are best served with tackling those limitations directly in Bloop/Seed. However, if someone wants to contribute additional generators, I am happy to provide some pointers.

[jvican]

The resulting build file will not be idiomatic and use unmanagedSourceDirectories for source paths, -Xplugin for Scala.js etc

I think we can work around these limitations in a nice way, generating idiomatic builds sounds more daunting than it actually is. Plus, it doesn't need to be perfect -- there is room for error and we could require user intervention. The generation just has to be good enough so that people consider it to migrate instead of doing everything from scratch.

I am also uncertain how useful the generated build will be.

IMO it will be useful to serve as a building block for the migration.

We are best served with tackling those limitations directly in Bloop/Seed.

Maybe, yeah. You could add support for publishing libraries through coursier publish/coursier release which I know @alxarchambault worked on.

However, the point to generate to other build files holds even if you fix these limitations. seed is really nice but doesn't have major adoption. If it positions itself at the very center of the build tools space and allows to generate other builds from it, then it would be in a privileged spot that could increase adoption as well as fix some of the major issues we experience when trying to teach Scala.

If this feature was supported, I'm pretty sure I could sell seed as the build tool to use for all the basic teaching in Scala (here at EPFL and also in ScalaBridge events and tutorials in the Internet).

[tindzk]

These are good arguments. Thanks for mentioning Coursier's publish command. I will see whether we can use it within Seed. I did not consider teaching Scala as a use case, though Seed might be a good fit here since sbt's syntax is too overwhelming for newcomers.

I can look into basic sbt support once some other more pressing issues have been resolved.

[jvican]

Sounds good to me! I cannot help with implementation but have too much experience with sbt, let me know if you have any questions on the generating idiomatic sbt builds part of the job.

I'm really excited about this, this is IMO a game changer 😄

[tindzk]

Sure, I will keep you in the loop. Thanks.

[nafg]

Technically I think it's possible to have an sbt plugin that generates the sbt projects and their configuration by reading a Seed file, rather than code-generating it. That doesn't solve all the problems in issue though.

[megri]

I'm not sure I like this idea. It seems to me like seed would become a stepping-stone to other build tools, when it is actually a competent build tool in its own right—I assume Mill "suffered" the same at some point, and probably Fury too.

If a migration from seed to whatever is desirable I feel that this should be implemented on the SBT/Mill side rather than included in seed itself. That way, the evolution of seed doesn't get tied to the evolution of other build tools.