• scala/toolkit#14

I ran the example code from the README and it doesn't print anything:

➜  toolkit git:(main) ✗ scala-cli toolkit.sc
Compiling project (Scala 3.2.2, JVM)
Compiled project (Scala 3.2.2, JVM)
➜  toolkit git:(main) ✗ 

I'm not sure if this is because of scala-cli or Cats Effect.

Scala Toolkit supports 2.12. All of our libraries do so far, so it's not any extra effort to do it here.

But, why. Here you go @SethTisue 😜

It'd be cool if the toolkit could work with Scala Native 0.5.x (0.5.1 as of me writing this)

scala-cli -e 'println("Hello")' --toolkit typelevel:0.1.25 --native --native-version 0.5.1
# Downloading compiler plugin org.scala-native:::nscplugin:0.5.1
# Downloading Scala Native CLI
# Downloading 4 dependencies and 2 internal dependencies
# [error]  Error downloading org.typelevel:toolkit_native0.5_3:0.1.25
# [error]   not found: /Users/pchabelski/.ivy2/local/org.typelevel/toolkit_native0.5_3/0.1.25/ivys/ivy.xml
# [error]   not found: https://repo1.maven.org/maven2/org/typelevel/toolkit_native0.5_3/0.1.25/toolkit_native0.5_3-0.1.25.pom
# [error]   not found: /Users/pchabelski/Library/Caches/ScalaCli/local-repo/1.2.2/org.typelevel/toolkit_native0.5_3/0.1.25/ivys/ivy.xml
# [error]   No fallback URL found
# [error] COMMAND_LINE

Here's the one posed by Virtus Lab:

Imagine you have a common business problem to solve. You need to write a program that fetches text from a web service and then creates a file in the local filesystem with content and path based on the downloaded information.

Scala Toolkit is getting a bunch of tutorials / examples, we can cheat by copying those and then slapping on a parTraverse 😝

• scalacenter/docs.scala-lang#8

I've tried using this toolkit for my Scala Native project, but it fails with

scala.MatchError: 16 (of class java.lang.Integer)

for both scala-cli and sbt on all platforms:

• https://github.com/andrzejressel/typelevel-toolkit-native/actions/runs/5272627423
• https://github.com/andrzejressel/typelevel-toolkit-native/actions/runs/5272627424

A common complaint is about the enormous amount of imports it takes to do stuff. e.g. http4s/http4s#6696

What if ... we just exported a bunch of useful stuff under a single package?

package typelevel.toolkit

export cats.*
export cats.effect.*
export fs2.*
export org.http4s.*
export org.http4s.ember.client.EmberClientBuilder
// etc.

Not gonna lie, it's playing with fire a bit. Probably instead of wildcards we should be thoughtful about the specific things we export.

But then:

import typelevel.toolkit.*

and you are off to the races!

Anything we wanna do prior to a first release? :)

When I trying running a simple http4s client app with Typelevel Toolkit, I get warnings about SL4FJ at startup:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

I can get rid of them with //> using dep ch.qos.logback:logback-classic:1.5.3
Maybe the toolkit should include a default logging implementation out of the box? I have no interest in remembering to configure logging when I'm trying to do a quick script.

Languages like python provide really fast and simple ways to perform most operations, which lends itself very well to scripting.
I think that Scala fails at this, while it's better than Java it's still not great. I don't think this is a problem for most situations.

I do however think it would be very nice if toolkit could provide default implementations of some common tasks in a referential transparent and resource-safe way. An example would be reading and writing files.

I'm pretty new to using CE so I ended up writing this, which I'm not even sure is the correct way to do this.

def fileWriter(path: String): Resource[IO, FileWriter] = 
    Resource.make(IO.blocking(new FileWriter(new File(name))))(file => IO.blocking(file.close()))
def openFile(path: String) : Resource[IO, Source] = 
    Resource.make(IO.blocking(Source.fromFile(path)))(file => IO.blocking(file.close()))

def writeToFile(path: String, content: String) =
    fileWriter(path).use(writer => IO.blocking(writer.write(content)))

if instead similar operations were already implemented for me I think that would be really great. It would at least make it a lot easier to convince other people to use this :)

All of this might obviously be outside of the scope of toolkit as it's a collection of libraries, but it would certainly make it easier to pick up for people who just want something to write small tools with.

This will be a huge win if we can land it.

• typelevel/cats-effect#3149

• scala/toolkit#37

It will be helpful to have tests in CI that check that the toolkit is able to compile a few test scripts.

I'm not sure we can achieve something like this, but we can try. WDYT @armanbilge?

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

But ... it's all bikesheddable :)