Which libraries?

[armanbilge]

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]

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?

[TonioGela]

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]

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

On it!

[armanbilge]

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]

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]

A couple ideas:

• circe-parser (definitely get that string into json, particularly files)
• circe-generic or generic-extras (both debateable, but if were doing automatic derivations here its a win for temporary script like stuff)

[armanbilge]

• we currently have circe-jawn, which is a 100% identical API to circe-parser (just replace circe.parser with circe.jawn). On JS it is faster and not broken for numerics 😁

  We can switch to circe-parser in the next major Circe release which includes: https://github.com/circe/circe/issues/1941 Unfortunately we decided not to backport that to the 0.14.x series

• 👍 to circe-generic but maybe only for Scala 2. On Scala 3 you can use derives with circe-core and I really hope nobody is trying to cross-build with toolkit because that sounds terrible 😁

[TonioGela]

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]

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

Yep we are rapidly converging to this 😂

[lenguyenthanh]

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

[TonioGela]

I have the name: typewholevel

[zetashift]

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]

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

[armanbilge]

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

[zetashift]

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

[armanbilge]

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

• https://github.com/typelevel/governance/issues/112

[zetashift]

Here are 2 spicey suggestions:

• http4s-server
• circe-generic

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]

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