Which libraries?

[armanbilge]

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

toolkit/build.sbt

Lines 17 to 25 in e644ae5

	libraryDependencies ++= Seq(
	"org.typelevel" %%% "cats-core" % "2.9.0",
	"org.typelevel" %%% "cats-effect" % "3.4.8",
	"co.fs2" %%% "fs2-io" % "3.6.1",
	"org.http4s" %%% "http4s-ember-client" % "0.23.18",
	"io.circe" %%% "circe-core" % "0.14.4",
	"org.http4s" %%% "http4s-circe" % "0.23.18",
	"com.monovore" %%% "decline" % "2.4.1",
	"org.typelevel" %%% "munit-cats-effect" % "2.0.0-M3" // not % Test, on purpose :)

But ... it's all bikesheddable :)

[TonioGela]

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

[armanbilge]

Heh, my bad. Sure!

[TonioGela]

@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]

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]

May I suggest:

• fs2-data: https://fs2-data.gnieh.org/
• ciris: https://cir.is/

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]

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]

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]

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]

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]

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]

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]

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?