Roadmap discussion

[joshgoebel]

To house discussion for the locked Roadmap #6.

The idea is to include the pieces needed to make wren-console a useful tool for general purpose console scripting out-of-the-box. Wren Essentials can currently be built and linked to Wren CLI also, but right now the primary use case considered is for the default wren-console bundling.

If maintained 3rd party libraries already exist that are critical then we will consider vendoring them. Our goal isn't to replace the great 3rd party community of packages with "one ring to rule them all". We'd love to see a system where it was trivial to bundle packages both separately and in a larger collection, such as essentials.

Pure Wren libraries should strongly be considered for inclusion via packaging though (currently via wren-package, rather than bundling. Though wren-console makes it trivially easy to bundle pure-Wren packages into itself.

[clsource]

Some modules that can be useful.

• String methods via C bindings: Ex: utf8 lowercase, utf8 uppercase, titlecase, compare ignoring case
• Cryptography and Hashes: Base64, SHA256, Bcrypt, MD5, HMAC, UUID
• Mustache Templates: https://gitlab.com/jobol/mustach (Template engine)
• SQLite or Unqlite https://github.com/symisc/unqlite (Persistent storage)
• Logger Kit (For more professional logger than System.print)
• Console Kit (Argument parser, and common UI in console apps)
• Networking Foundations (Curl, http server?)

[joshgoebel]

Just OTTOMH:

• Crypto sounds like a whole separate library, though I agree it would be useful to have.
• Ditto for SQLite, Unqlite, Mustache.
• A nice Logger class feels in-scope right now for sure (with various log levels, etc)
• Ditto for some more Strings baseline functionality.
• Argument parsing would be nice, but so many opinions. I'd like to let a 3rd party library win peoples love and then either pull it in (or let it live on it's own). I might be open to something uber-minimal... but I already think it's not really that hard to process arguments by hand... of course we already have https://github.com/nanaian/wren-args
• You'd have to elaborate on "common UI"... do you mean like ncurses dialog/UI type stuff?
• Some networking is definitely desirable, though that's a larger task I think. HTTP/HTTPS via Curl might be possibly be a quick win.

And currently everything we do here needs to be fully cross-platform... Linux, Mac, Windows (because wren-console currently is). Also I think it's important that people be building this stuff based on needed real world usage not just "well hey we really should have this cause everyone else does". I don't think that's how you build a cohesive library. Real world need means this stuff is actually getting used, battle tested, bugs fixed, etc... I don't want to build a ghost town library.

Pulling in the JSON lib that's already being used in the real-world from DOME was a great example I think.

[clsource]

Maybe another essential would be reading and writing env files like dotenv

https://github.com/Isty001/dotenv-c

[joshgoebel]

Well, before we can do anything useful with the environment we need ENV capabilities in the CLI, which currently do not exist, we likely need to wrap:

• uv_os_environ
• uv_os_unsetenv
• uv_os_setenv
• uv_os_getenv

Perhaps:

Process.env.all
Process.env["PATH"] 
Process.env["PATH"] = "/usr/bin/"
Process.env.unset("PATH")

Thats likely first a todo/discussion for Wren CLI and Wren Console, as I think environment should be part of the CLI core library...

[clsource]

Other possible feature is date manipulation using https://github.com/hroptatyr/dateutils

[clsource]

Just to share the idea a wren formatter and linter command with a modified wrenanalizer would be cool too

[joshgoebel]

I've already started playing with that idea but I have no idea if I'll finish it.

[clsource]

A good foundation would be an AST that outputs a map or json. Then the formatter or linter can use that.

wrenc ast code.wren

{
 "ast": {}
}

import "json" for JSON
import "essentials" for AST

var astMap = AST.parse(text)
System.print(JSON.encode(astMap))

[joshgoebel]

Does the existing stuff not have an AST already or is it not general enough? I don't see any reason this wouldn't be a library... I meant an ast tool maybe it fun on it's own, but I wouldn't expect to use it. I'd use an AST library or something to parse the source myself, etc... but if all your saying is a workable AST is the first step, I mostly agree.

I was actually going to try a pass with JUST the lexer, and I'm sure you could get something workable but an AST would be better for sure. :)

[clsource]

The ast command can be used by other programs in the future. Maybe a wren language server? Highlighter? A transpiler maybe? Who knows :)