OS module

[fwbrasil]

I started working on an integration with os-lib but never had time to finalize it. We need a module in Kyo that provides primitives for dealing with files and issuing system commands.

I'm not sure if we should keep building it on top of os-lib since it's not designed to be integrated with effect systems.

[hearnadam]

What would be the minimum set of operations this should include?

[fwbrasil]

I expect the main use of the module to be by people working with LLMs. They typically need to read and write files, especially CSVs. I think it's essential to provide simple APIs for this use case, but we could also choose to have a broader scope similar to os-lib. Another alternative would be to check with the os-lib developers if they would be open to providing a parameterized API to integrate with effect systems. It should be possible to provide the reusable parameterized API but also "lower" it to continue offering os-lib's impure APIs (basically binding to an identity effect).

[johnhungerford]

Why do you expect LLM work to be the main use? Is this a general design goal of kyo? There are a lot of use cases requiring reading and writing files.

For my part, here's what I would need:

1. Read file as bytes or string
2. Write bytes or string to file
3. Append bytes or string to file
4. Stream bytes or string chunks from a file
5. Stream lines from a file
6. Sink a stream of bytes or strings into a file
7. Sink a stream of strings into a file as lines
8. Stream files from a directory
9. Stream files from a directory recursively
10. Move, copy, remove a file/directory

[fwbrasil]

Why do you expect LLM work to be the main use? Is this a general design goal of kyo?

The market for Kyo within the current Scala community seems too limited. The community has been consistently shrinking, a significant portion of it has a strong bias against me and the project, and capturing market share from cats-effect and ZIO doesn't seem very feasible. I'd say companies are more likely to rewrite in another language than to adopt Kyo.

I wouldn't say that's a design goal but an attempt to find a new market to make the library viable in the long term and ensure it evolves as a healthy OSS project. I'd say there's a good chance LLMs will become the "killer application" for Kyo.

There are a lot of use cases requiring reading and writing files

Cool! And we have Streams now :) I don't think we need to limit the scope of this ticket. My comment was more in the direction of simplifying the initial scope of the module if necessary.

[fwbrasil]

/bounty $500

[algora-pbc[bot]]

## 💎 $500 bounty • Kyo

### Steps to solve: 1. Start working: Comment /attempt #220 with your implementation plan 2. Submit work: Create a pull request including /claim #220 in the PR body to claim the bounty 3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to getkyo/kyo!

Add a bounty • Share on socials

Attempt	Started (GMT+0)	Solution
🟢 @pablf		#428

[fwbrasil]

Bounty requirements:

1. Comprehensive set of primitives to read/write files, including with Streams
2. APIs to issue shell commands

[algora-pbc[bot]]

💡 @pablf submitted a pull request that claims the bounty. You can visit your bounty board to reward.

[algora-pbc[bot]]

🎉🎈 @pablf has been awarded $500! 🎈🎊

• Share on socials
• Give feedback

[fwbrasil]

fixed by https://github.com/getkyo/kyo/pull/428