Plan for @main and mainargs in Scala3?

Language Design
21

Perhaps the correct question should be: what is the outstanding work to make MainAnnotation stable?

In its experimental form it’s already been possible to produce very useful annotations: `ioMain` annotation for blazing fast getting started experience (Scala 3.2+) · Issue #3149 · typelevel/cats-effect · GitHub, but it looks like the stabilisation has stalled as of recently?

2 Likes
22

It’s worth mentioning that com.lihaoyi::mainargs just released a new version 0.6.1

Anyone who wants to parse CLI arguments for real work really should be using mainargs. There’s a lot of subtlety to parsing CLI arguments, a lot of it mainargs handles for you (look through the docs). I already mentioned a lot of the complexity in the original post, but there’s even more things like:

  • Combining multiple flags and values, e.g. git commit -amMyMessage v.s. git commit -maMyMessage
  • GFlag’s style --key=value, or --key=
  • Passing key-value pairs to a flag in one token e.g. java -Dtest="true"
  • Automatic conversion to CLI naming conventions, e.g. an argument named camelOptFor29Arg being passed as --camel-opt-for-29-arg or --camel_opt_for_29_arg

I do not think we want Scala 2 or Scala 3 compiler teams to get into the business of managing the subtleties of CLI argument parsing, and neither should we point people at solutions that look great on a slide but don’t work for real world use cases. We should just point developers to a library that works, the closest being mainargs

6 Likes
23

I still use the singleton object extended from App. It allows for flexibility when I need it and I can have multiple entry points in my codebase.