Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Srepfler Srdan
    @schrepfler
    it compiles to scala-js so I guess it should port to scala-native easily
    Ryan Williams
    @ryan-williams
    ah ok, whereas shapeless does not?
    Srepfler Srdan
    @schrepfler
    import cats.data._
    
    // a coproduct of types using scala.util.Either
    type EitherFoo = Either[Int, Either[String, Double]]
    
    // a coproduct of type constructors using cats.data.EitherK
    type EitherKBar0[A] = EitherK[List, Seq, A]
    type EitherKBar[A] = EitherK[Option, EitherKBar0, A]
    that’s the first example
    so I guess it’s impled
    shapeless already compiles to scala native, so that’s a plus in my book
    Ryan Williams
    @ryan-williams

    ok, not totally understanding why i'd want one or the other yet.

    but anyway, for the case-app API above, it seems like you'd have to generate an HList with the union of all fields in the hierarchy (i.e. all branches of all coproducts + all fields in all products, recursively), parse the user-provided args into such an HList, and then thread that unioned HList back into a path through the hierarchy…

    Srepfler Srdan
    @schrepfler
    ideally I’d only want to use case statements no?
    let me try to write an example
    let’s say we have the options as above
    This message was deleted
    Ryan Williams
    @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
    @schrepfler
    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
    @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
    @schrepfler
    I think so
    Ryan Williams
    @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
    @schrepfler
    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
    :D
    but for case-app I think it would be a good thing to support coproducts
    Ryan Williams
    @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
    @schrepfler
    :+1:
    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
    Jorge
    @jvican
    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
    @alexarchambault
    @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
    Jorge
    @jvican
    Thanks for the answer :+1:.
    Guillaume Massé
    @MasseGuillaume
    Is it possible to generate a sbt parser from CaseApp ?
    Ryan Williams
    @ryan-williams
    nit: seems like 2.0.0-M3 doesn't have a tag on github
    Ryan Williams
    @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
    @ryan-williams
    (looks like you override it directly on the CommandApp)
    Ryan Williams
    @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
    @NicolasRouquette
    FYI: I added a feature for expanding @<file> argument files into arguments here:
    alexarchambault/case-app#97

    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)
            argText.split(EOL).map(_.trim).filter(_.nonEmpty).toList
          } else {
            List(arg)
          }
        }
      }
    }

    Does anyone have a suggestion for that?

    Leif Battermann
    @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
    @Krever
    Hey, are sub-commands supported in case-app?
    Alexandre Archambault
    @alexarchambault
    @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)