search

typelevel / toolkit

Quickstart your next app with the Typelevel Toolkit!
https://typelevel.org/toolkit
Apache License 2.0
92 stars 9 forks source link

Which libraries? #1

Open armanbilge opened 1 year ago

armanbilge commented 1 year ago

The current choices mirror what's in the official Scala Toolkit (sttp, upickle, oslib). I also added Decline :)

https://github.com/typelevel/toolkit/blob/e644ae55d7c4a15551b1f9f9594f6f42eaf75fb5/build.sbt#L17-L25

But ... it's all bikesheddable :)

TonioGela commented 1 year ago

Since we're here, why not decline-effect? I prefer to do not have to reimplement CommandIOApp.

armanbilge commented 1 year ago

Heh, my bad. Sure!

TonioGela commented 1 year ago

@lolgab made me notice that w/o importing epollcat the native flavour of the toolkit is quite useless atm. Do we wanna add either epollcat only to the native build or namespacing the imports like toolkit.IOApp to take the correct implementation according to the platform? Also, I'm aware of this PR but until it gets merged toolkit on its own is not sufficient for writing a native app

armanbilge commented 1 year ago

on its own is not sufficient for writing a native app

Well, not for writing a native app that uses networking. But it's perfectly fine for file-based scripting.

The thing is, the toolkit can never be sufficient for this usecase, because the user also needs to install and configure s2n-tls anyway. So for Native, additional involvement will always be required, and as you point out it will get easier in the near future.

I almost considered not publishing for Native yet, but the file-scripting aspect seemed valuable.

zetashift commented 1 year ago

May I suggest:

Because configs and parsing CSVs happen frequently enough (for me) to have them in the toolkit. However I very much understand the fact that it might be overkill.

armanbilge commented 1 year ago

Ah, but the catch with fs2-data is that everything is in a separate module. So ... should we bring in all the modules? 😂 That might be overkill.

zetashift commented 1 year ago

IMO, the CBOR and JSON modules don't need to be pulled in. I don't know what cbor is and we already have circe. xml might be a nice to have, kinda depends. But I only ever had to deal with parsing XML once in my life sooooo.... :P

The csv saved my ass several times in scripts tho.

TonioGela commented 1 year ago

IMO, the CBOR and JSON modules don't need to be pulled in. I don't know what cbor is and we already have circe. xml might be a nice to have, kinda depends. But I only ever had to deal with parsing XML once in my life sooooo.... :P

The csv saved my ass several times in scripts tho.

IMHO, if we have to pick just one module, I'll pick the csv one. cbor might be funny to have since the VirtusLab toolkit has uPickle as a tiny serialization format, but it's probably a bit overkill too.

If this toolkit is supposed to be a pack of dependencies meant to be used for scripting purposes I think fs2-csv is a perfect fit, otoh I can't imagine the need for Ciris in a script-ish group of dependencies (unless at a certain point you do want to promote the script to a "beefier" application). What do you think?

zetashift commented 1 year ago

I think that for now, only using the csv module is sufficient for the toolkit. Can always bikeshed later on, but for now I don't see their immediate gain.

If this toolkit is supposed to be a pack of dependencies meant to be used for scripting purposes

Not really related to this issue but, I think it's a good idea to state the goal of typelevels toolkit more explicitly in the README.md. Personally, I'd like to see this project being used as a very low-entry easy-to-use standard library for making scripts/small applications using FP (or programs-as-values). I consider loading configs/secrets etc to be part of the "small applications" thing. Heck I'd even argue that http4s-server should be included as well (like Go's stdlib).

Thinking it through and seeing the nature of scala-cli and the fact that in smalls app, people would probably sooner switch to sbt or mill, I think I agree with you, there is no need for Ciris in scripts and thus also no (current) need for it to be included here. But maybe it can be re-considered again depending on use-cases developing over time.

satabin commented 1 year ago

I agree with what has been said, in the context of scripting, fs2-data CSV (potentially the generic one even though it brings shapeless) would be a good fit here.

TonioGela commented 1 year ago

Not really related to this issue but, I think it's a good idea to state the goal of typelevels toolkit more explicitly in the README.md.

I'm working on the site, and I was thinking about that. Probably claiming that it's MEANT to be used for scripting it's a strong claim.

I mean it's a meta lib that brings in CE, fs2, an http client, a json parser, a command line argument parser and a testing lib. It contains more features than most of the languages' standard lib have.

zetashift commented 1 year ago

I mean it's a meta lib that brings in CE, fs2, an http client, a json parser, a command line argument parser and a testing lib. It contains more features than most of the languages' standard lib have.

True! And I can get behind this, but if this is a bikeshedding issue then I just felt obliged to do it :P.

Also is it okay if I open up the PR for fs2-data-csv?

TonioGela commented 1 year ago

Also is it okay if I open up the PR for fs2-data-csv?

Totally! go on :D I count on you for a fs2-data-csv example for the site once it's ready :)

TonioGela commented 1 year ago

@zetashift the site is live @ https://typelevel.org/toolkit, if you add a fs2-data-csv example we can hit the 0.0.3 release :)

zetashift commented 1 year ago

On it!

armanbilge commented 1 year ago

A discord question from @lenguyenthanh made me realize: shall we add Kittens? Automatic typeclass derivation sounds toolkitty to me :) at the very least for basic stuff like Show, Eq, maybe Monoid. anyone using it regularly?

https://github.com/typelevel/kittens

lenguyenthanh commented 1 year ago

shall we add Kittens? Automatic typeclass derivation sounds toolkitty to me :) at the very least for basic stuff like Show, Eq, maybe Monoid. anyone using it regularly?

A yes for me, I started using it and definitely love it. It made me want to use type class more :D

ChristopherDavenport commented 1 year ago

A couple ideas:

armanbilge commented 1 year ago
TonioGela commented 1 year ago

A discord question from @lenguyenthanh made me realize: shall we add Kittens? Automatic typeclass derivation sounds toolkitty to me :) at the very least for basic stuff like Show, Eq, maybe Monoid. anyone using it regularly?

To be fair I don't use it that much, so I'm not sure which is the correct thing to do. Toolkit is not limited to being used in small script-ish applications created with scala-cli but it's a fully-fledged library that can be used in huge sbt projects too. I'm just afraid that eventually it will include every TL library ever. What do you all think?

[EDIT] Now that I'm thinking about it I'll prefer to add small utility libs like mouse, but again, that's just my view :)

I really hope nobody is trying to cross-build with toolkit because that sounds terrible 😁

🤣

armanbilge commented 1 year ago

I'm just afraid that eventually it will include every TL library ever.

Yep we are rapidly converging to this 😂

lenguyenthanh commented 1 year ago

maybe this is a stupid idea, but how about a typelevel toolkit and typelevel fat toolkit (which includes everything lol)?

TonioGela commented 1 year ago

I have the name: typewholevel

zetashift commented 1 year ago

I am okay with libraries like kitten and mouse (mouse is really cool!).

Also a vote for https://github.com/typelevel/squants but this is more because F# has units of measures and I've found it very nice for small "business logic" focused applications.

I, personally, wouldn't like to have 2 versions of the toolkit. It just seems like more options, while one of it's nice properties is that it's just 1 import and it's just there. No need to think more about it unless you need some specific functionality.

I'd much rather have a "too big or too small" toolkit with endless bike shedding than having to explain when to use what. I want to think as little as possible when using toolkit.

--

How about some project templates (using giter8 or something) that includes a project.scala that imports a whole lot of TL libraries? Or maybe a poll/survey for FP people to see what they would like to see included? Dunno just throwing stuff out there :P.

ppurang commented 1 year ago

What's the motivation behind using munit instead of weaver-test?

armanbilge commented 1 year ago

Arbitrary decisions :) we're considering changing to weaver, see discussion here.

zetashift commented 1 year ago

Can't hurt to include MUnit + Weaver in the test artifact no? Atleast to start?

armanbilge commented 1 year ago

@zetashift @ppurang there is a proposal to make Weaver an official Typelevel project, once that goes through I propose we add it / swap it out.

zetashift commented 7 months ago

Here are 2 spicey suggestions:

Go, Zig and Node.js(Bun/Deno as well) all have a http server included in their standard library. So atleast it's worth bikeshedding about :P.

And circe-generic because I'm lazy to write manual codecs.

armanbilge commented 7 months ago

Go, Zig and Node.js(Bun/Deno as well) all have a http server included in their standard library.

Yeah, ember-server. But then probably we'd need to bring in the http4s DSL as well, and that's opening cans and cans of worms :)

And circe-generic because I'm lazy to write manual codecs.

Actually you don't need it on Scala 3, derives works out-of-the-box. e.g. https://github.com/typelevel/await-cirrus/blob/3f7307dc8a6775ef199735621254c320add46f8b/index.scala#L68

zetashift commented 7 months ago

Go, Zig and Node.js(Bun/Deno as well) all have a http server included in their standard library.

Yeah, ember-server. But then probably we'd need to bring in the http4s DSL as well, and that's opening cans and cans of worms :)

:smiling_face_with_tear: life can be tough.

Actually you don't need it on Scala 3, derives works out-of-the-box. e.g. https://github.com/typelevel/await-cirrus/blob/3f7307dc8a6775ef199735621254c320add46f8b/index.scala#L68

Huh gotta revisit my scripts then, I had to pull in circe-generic for things to compile, using Scala 3 as well.

SethTisue commented 7 months ago

Maybe someone knowledgeable could add a section to the README with a list of the likeliest things people might want that aren't included, with links? This would mitigate the inconvenience/confusion factor in cases where including something seemed at least halfway plausible but a decision was made to leave it out.

At minimum, such a list would certainly include "http server". Not sure what else it would/should include.

After the list, there could even be a link to this ticket.

If there is some concise, beginner-friendly guide/map to the Typelevel ecosystem out there, linking to that, that'd be amazing too. Or to whatever the best available thing is, such as https://typelevel.org/projects/

TonioGela commented 7 months ago

Go, Zig and Node.js(Bun/Deno as well) all have a http server included in their standard library.

Yeah, ember-server. But then probably we'd need to bring in the http4s DSL as well, and that's opening cans and cans of worms :)

🥲 life can be tough.

Actually you don't need it on Scala 3, derives works out-of-the-box. e.g. https://github.com/typelevel/await-cirrus/blob/3f7307dc8a6775ef199735621254c320add46f8b/index.scala#L68

Huh gotta revisit my scripts then, I had to pull in circe-generic for things to compile, using Scala 3 as well.

This seems like a spontaneous application for writing a auto derived json converting example

zetashift commented 7 months ago

This seems like a spontaneous application for writing a auto derived json converting example

Just need the right inspiration for a runnable example!

daddykotex commented 7 months ago

Actually you don't need it on Scala 3, derives works out-of-the-box. e.g. https://github.com/typelevel/await-cirrus/blob/3f7307dc8a6775ef199735621254c320add46f8b/index.scala#L68

It seems to only work for Decoder

TonioGela commented 7 months ago

Actually you don't need it on Scala 3, derives works out-of-the-box. e.g. https://github.com/typelevel/await-cirrus/blob/3f7307dc8a6775ef199735621254c320add46f8b/index.scala#L68

It seems to only work for Decoder

//> using toolkit typelevel::latest
//> using scala 3.3.1

import io.circe.*
import io.circe.syntax.*

case class Foo(bar: String) derives Codec.AsObject

object Main extends App:
    println(Foo("hello").asJson.noSpaces)
{"bar":"hello"}

Codec and Encoder have a few implementations, namely AsObject, AsArray, AsRoot and AFAIK only AsObject has autoderivation ( I think this might be a question for circe not TL toolkit though :D )

daddykotex commented 7 months ago

Codec and Encoder have a few implementations, namely AsObject, AsArray, AsRoot and AFAIK only AsObject has autoderivation ( I think this might be a question for circe not TL toolkit though :D )

ahh makes sense, I completely overlooked that

reardonj commented 3 months ago

I was playing around with Scala CLI today, for some simple HTTP client scripting. I was very surprised no XML library was included. I added http4s-fs2-data-xml-scala to get my use-case working but IMO, it would be very nice to have XML supported out of the box as it is the other common HTTP API data format.