Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
    Srepfler Srdan
    This message was deleted
    Ryan Williams

    i was just trying to brainstorm how the case-app implementation might work under the hood.

    in my mind, the API would look just like it does today except some arguments could be sealed traits (maybe always @Recurse-tagged?), and case-app would Just Figure It Out

    Srepfler Srdan
    sealed trait A
    case class B(f: String, n: Int) extends A
    case class C(f: String, s: String) extends A
    case class Args(
      @Recurse a: A,
      otherArg: String
    object Hello extends CaseApp[Args] {
      def run(args: Args, arg: RemainingArgs): Unit = {
    args.a match {
      case B(f, n) => …
      case C(f,s) => ...
    not sure how would a map work with a coproduct
    ideally a map would return just that one thing
    and than one could do case on it for tha various possibilities
    Ryan Williams
    that usage looks good but that's already how sealed traits work in scala, i.e. you get static-checked match/case, right?
    Srepfler Srdan
    I think so
    Ryan Williams
    ok, yea i agree that's how you would use it :)
    have you looked at how the Parser works for HLists today?
    Srepfler Srdan
    no, I didn’t go much in-depth to be honest, I just had a question that day :D
    in the end I said to myself to leave the cli tool to allow using both at the same time
    but for case-app I think it would be a good thing to support coproducts
    Ryan Williams
    yea, agreed. i will have to look in there again sometime and try to figure out how to make the parser handle this
    Srepfler Srdan
    I think what you said about parsing the stuff into an HList made a lot of sense
    perhaps some gards to warn about options being exclusive
    plus presenting the coproducts nicely in the —help
    I love caseapp, but I think that the fact that it depends on Shapeless is killing me
    It's really slow to compile bloop because of it
    @alexarchambault Do you think it would be possible to migrate caseapp to use Magnolia for the derivation?
    Alexandre Archambault
    @jvican I'm not sure that can be done… case-app relies quite a lot on shapeless stuff to get default values, annotations, etc. (all via type-level things)
    Last time I checked, it didn't seem magnolia could handle those
    Plus the code in magnolia doing what shapeless.Generic does, seemed hmm… quite naive for now
    There are litterally dozens of corner cases that shapeless handles, that a new library is unlikely to be fine with
    Thanks for the answer :+1:.
    Guillaume Massé
    Is it possible to generate a sbt parser from CaseApp ?
    Ryan Williams
    nit: seems like 2.0.0-M3 doesn't have a tag on github
    Ryan Williams
    where do I put AppName when I am using Commands? I can't get it picked up anywhere i've tried
    Ryan Williams
    (looks like you override it directly on the CommandApp)
    Ryan Williams

    I want to make broader use of the Default type-class, but putting the obvious implicit in scope:

    implicit def valueFromDefault[T](implicit default: Default[T]): T = default.value

    seems to cause diverging implicit expansion errors on a lot of existing implicit resolutions, and not work the way I want.

    any insight into why that's the case?

    Nicolas Rouquette
    FYI: I added a feature for expanding @<file> argument files into arguments here:

    One thing I didn't have time to do is port the following code to scala.js:

    package caseapp.core.parser
    import java.nio.charset.StandardCharsets.UTF_8
    import java.nio.file._
    import scala.compat.Platform.EOL
    object PlatformArgsExpander {
      def expand(args: List[String]): List[String] = {
        args.flatMap { arg =>
          if (arg.startsWith("@")) {
            val argPath = Paths.get(arg.substring(1))
            val argText = new String(Files.readAllBytes(argPath), UTF_8)
          } else {

    Does anyone have a suggestion for that?

    Leif Battermann
    Is there a way to control the error message when parameters are missing? Currently I get [error] Required option --propertyName not specified. I think it should be [error] Required option —property-name not specified.
    Wojtek Pituła
    Hey, are sub-commands supported in case-app?
    Alexandre Archambault
    @Krever Not yet
    Although I guess some basic support could be more or less easily added
    The CommandName annotation ought to be read by case-app
    If it contains a space (like @CommandName("install path")), it could assume this is part of a sub command.
    Then the command parser could be tweaked to accept those (like checking if all parts of such a command are there, instead of just checking for a single word right now)
    Lawrence Carvalho
    hey, wondering if someone can help me. I was looking to be able to create a custom arg parser for my case class by invoking the derivation mechanism and then mapping over the result so I could apply some custom validation on top. Is this possible?
    I've been looking for something like derive[T].map but i can't seem to find any way of doing something like that
    Pritam Kadam


    > coursier --help
    Coursier 2.0.0-RC4
    Usage: coursier [options] [command] [command-options]

    what does [Options] represents here?

    Corey O'Connor
    @kpritam that doesn't seem to be a caseapp question?
    [options] are application-wide options. Not specific to a command
    For example: logging levels are often global to an application.
    those would be appropriate to [options]
    Srepfler Srdan
    @alexarchambault if I'd like my app to support piping which I suppose would map nicely to some sort of a stream abstraction, is this possible with case-app?
    Srepfler Srdan
    @alexarchambault what if case-app would provide an extension, an implicit which, when imported, would provide an fs2 Stream which would convert the stdin stream to an fs2 stream