What's missing for mill 1.0?

[lefou]

I guess mill is pretty stable to use it for larger projects on an everyday basis. So, what's holding us back to just release a 1.0?

I'd like to collect some feedback about what you think is missing?

Although I have a rather long personal wish list, most of these wishes are not holding back a 1.0 except maybe one: We need a stable API! And to ensure, that our API is stable, we need some mechanism to detect when we broke it. After we have this, we will be able to evolve further, following semantic versioning. We may raise the version as we go, but keep strong API guarantees for micro/patch version releases.

[lihaoyi]

Yeah some definition API stability would I think be a big one. We could of course continue to evolve the system over time, with 2.x and 3.x and 4.x etc., but going from 0.x to 1.x we really need to have a better strategy around backwards compatibility than "things might break at any time" (even if in practice they usually don't)

There's also the question of what compatibility guarantees we want to follow. For my other projects (Ammonite, FastParse, etc.) I've gone with a model where a project of version x.y.z means:

• Bumping x means everything was overhauled, and most users will need to adapt
• Bumping y means there's likely some breakage, but minor, and maybe only for subsets of users
• Bumping z means there's probably no breakage for the vast majority of users

This conventions is significantly less strict than full Semantic Versioning, but I think has served the other projects well and could be considered for Mill as well

[lefou]

Personally, I find that scheme to vague. I'd rather like to bump versions or postpone changes. I think we should define which modules are assumed to be core (e.g. mill-api, scala*lib) to drive the decision. Bumping even when there is no need for it from a compatibility standpoint is ok.

[hmf]

@lefou Probably not the answer you are looking for but a "cookbook" for Mill would be nice. It will save on repeatedly answering the same/similar questions. I think that it could also double as an API check. By using something like tutor mdoc one could easily check for breaks - compilation would simply fail (for Scala 3 scala3doc may may also do this). Deprecated API calls could also be documented.

My 2 cents :-)

I would also like to acknowledge the great work both @lihaoyi and you have done.

[lefou]

My hope was, that we can use the Github Discussions forums as a tool to find frequently asked questions. Also, with the new documentation site, collaboration is much improved. For each page you find an edit link in the upper right corner. Also, that way everybody knows where the documentation sources are located and adding new pages should be straight forward.

[hmf]

Nice. Didn't realize documentation had been upgraded. Also very nice you indexed it by build. Did not know of https://antora.org/.

[ckipp01]

One thing I'd absolutely love to see done before a 1.0 release (from my own selfish desire) is to see this taken across the board #899. The current BSP support that Mill has is very IntelliJ focused and is still sort of un-usable for Metals users, primarily because of these two issues:

• [BSP] - Support for workspace/reload #986
• [BSP] - Diagnostics not being cleared after successful compilation #987

I know you have a pretty large refactoring started in order to try to better support workspace/reload here: #1093, which is probably the biggest thing to get across the board first. Is there still plans to finish this? I'd love to be able to offer the same type of support for Mill BSP as we do for sbt BSP in Metals, where the .bsp/mill-bsp.json file can be auto-created by Metals, and the entire process smoothed out. If that's not on the board for the moment, no pressure, I'd just love to see Mill BSP right up there with Bloop and sbt for Metals users.

[joan38]

Hi guys,
Sorry I've indeed not been so much envolved lately.

I have tried 0.10.0-M4 just now and noticed that imports are now red in .sc files:

I believe this is due to this commented code:
https://github.com/com-lihaoyi/mill/blob/main/bsp/src/mill/bsp/MillBuildServer.scala#L383-L389
Any reason that was removed?

[lefou]

@joan38 The module that represents the mill build project itself (https://github.com/com-lihaoyi/mill/blob/main/scalalib/src/mill/scalalib/bsp/BspModule.scala#L76) is already a JavaModule, that's why we no longer need to special-case it in all BSP endpoints. But the commented out code should be removed, of course.

[lefou]

Please note, that if you've used Mill BSP in IJ IDEA, that the rich editor experience was most probably not because of our BSP implementation, but because IJ IDEA has dedicated support for Ammonite scripts.

Ammonite itself has a BSP server and it would be great, if we could somehow use it in our BSP implementation. Our ticket for it is: #971 It is structured differently, e.g. is provides a BuildTarget for each .sc files, so we can't simply forward to it. I already asked in Ammonite gitter channel for a guide, but unfortunately didn't received any help. Essentially, we need a proper way to retrieve a) the dependencies of a .sc script (includes, ivy deps) and b) provide compile support for them (including the correct Mill predef when compiling build.sc).

[joan38]

No, this due to the classes not being in the local cache. See https://blog.jetbrains.com/scala/2018/05/07/ammonite-support/
That used to be pulled by the function getMillBuildClasspath. Even if it's a JavaModule it needs special handling.

[lefou]

@joan38 Thanks, I overlooked that. I opened PR #1568 to re-add support for $ivy imports.

[shishkin]

Maybe a cleanly running CI and a contributor's guide would help? Currently getting started hacking on Mill codebase is quite frustrating.

[lefou]

In my eyes CI runs very clean, all green, since 0.10.0 tag. Can you elaborate on what frustrates you? This might help to find the items needed to add to an contributors guide, to which I completely agree.

[shishkin]

I've tried a PR that arguably was way too complicated for someone new to take on: #1685. Local test run failed for me even on clean main (see #1719 (comment)). The CI checks were all red with different seemingly unrelated failures (https://github.com/com-lihaoyi/mill/actions/runs/1720624889) and combined with local failing tests not really encouraging to look for errors in own code.

Contributor's guide could describe how to set up a working environment (versions of required software, IDE, BSP vs Bloop etc.) and avoid common pitfalls, what tests to run (and which ones can be ignored in local setup), how to write a repro test for a bug report and how to see it fail.

[lefou]

Parts of these questions should be already answered in the Readme.