[ANN] - TryIt.jl An interactive UI environment to experiment with Julia packages (Experimental / WIP) and ManyUI ecosystem

Package Announcements
1

Hi everyone,

I’m sharing an early, experimental project called TryIt.jl. Inspired by the quick workflow of tools like try-cli and/or try-rs, this package explores how we can build rich, interactive interfaces to test and play with Julia code (but also other code).

image
image3408×1850 203 KB

Disclaimer: This project and its companion UI libraries are at an early experimental stage, rapidly evolving, and currently unregistered. Expect breaking changes, rough edges, and exploratory code. (Note: TryIt.jl does not currently sandbox environments. It is focused on the user interface experience).

What is TryIt.jl?

Instead of just typing in a standard REPL, TryIt.jl aims to provide a more visual, interactive layer to explore APIs and test snippets. The core of this project is heavily tied to experimenting with different UI backends in Julia.

Architecture & UI Experiments

Under the hood, the project is exploring different interfaces to achieve this:

  • Tachikoma.jl: Currently used to drive the terminal/TUI interactions (main branch)
  • ManyUI.jl: An experimental abstraction layer (explored in dedicated branches) designed to bridge multiple UI backends (TUI, Web, etc.) from a single codebase. Documentation and concepts for this architecture are available on the ManyUI documentation site.

Links & Code

The Vision: ManyUI Ecosystem & Python Inspirations

​TryIt.jl also serves as a primary testbed for a much broader initiative: the ManyUI ecosystem. Inspired by the ergonomics and design philosophy of Python’s Textual framework and its broader ecosystem (such as Rich), ManyUI aims to provide a unified abstraction for UI development in Julia. The ultimate goal is to write the interface logic once and project it seamlessly across multiple backends, whether that is a rich Terminal UI (TUI), a Web interface (either true native web or terminal in web interface), or a native desktop application (through CImGui). Building robust multi-backend UI projections is a complex challenge, and TryIt.jl is the first practical playground to refine this architecture.

Trying it out

Since the packages are unregistered, you can test it directly via Git:

using Pkg
Pkg.add(url="https://github.com/JuliaTryIt/TryIt.jl")

I am primarily looking for feedback on the UI abstractions (Tachikoma/ManyUI integration) and ideas on how to improve this interactive workflow. Thoughts and PRs are very welcome via GitHub issues or in this thread!

2

very cool :slight_smile: i have one question tho: will it support sandboxed execution of packages in the future? like if you want to try a package you are not sure about, not sure if that is possible, but i think it will be a very useful feature
anyway, its very cool! keep going!

3

Hi @sinisterMage, thanks for bringing this up!

Security and isolation are definitely critical issues when building environments to test untrusted packages. While TryIt.jl doesn’t sandbox code by default right now, I am actually experimenting with two complementary projects to tackle this exact problem. I am not a hardcore sandboxing specialist (nor a payload builder specialist :laughing:), but I fully grasp the stakes, especially regarding obfuscated code and “scientific disguises”.

Here is what I am currently working on in the background:

1. PluginGuard.jl (Private WIP)

This is an experimental defense-in-depth layer (currently private, but activated via a TryIt.jl extension). It tackles the reality that code mimicking harmless numeric data can still execute arbitrary commands.

The Motivation: A malicious payload can be easily encoded as a set of floating-point “constants” in a fake physics module. By leveraging Julia’s reflection capabilities and dynamic symbol resolution at runtime, that benign-looking data can be reconstructed and evaluated as a system command. Since no explicit execution literals ever exist in the source code’s AST, standard grep-like tools are completely blind to it.

PluginGuard aims to provide two layers:

  • TrustCheck: A portable, dependency-free static scanner. Instead of looking for explicit malicious strings, it analyzes the AST to flag the structural “tells” of these execution patterns (like reflection abuse, network calls, or obfuscation signatures) before anything runs.

  • PluginSandbox: A cross-platform (Linux / macOS / Windows) dynamic gate that vets code with TrustCheck and then runs it under the strongest isolation the host offers: a locked-down Docker/Podman container, falling back to a killable Malt.jl worker.

2. YARA_X.jl (also Private WIP)

To complement this, I am also working on YARA_X.jl. It is a high-performance Julia wrapper for the yara-x C library, bringing robust malware pattern matching to the Julia ecosystem. It features safe memory management (wrapping C pointers in mutable structs with reliable finalizers) and deep metadata extraction.

The Synergy between the two:

Because YARA is primarily a lexical (string/regex) scanner, it doesn’t understand the Julia AST. It is incredibly fast for detecting known malware binaries, but a simplistic YARA rule targeting dynamic symbol resolution will likely falsely flag legitimate metaprogramming or serialization frameworks in Julia.

This is where the two tools pair perfectly:

  • Use YARA_X.jl as an ultra-fast first line of defense to instantly block established malware signatures (IoCs) and binary payloads with near-zero false positives.

  • Use PluginGuard.jl as a semantic analyzer to catch novel supply-chain attacks by parsing the actual Julia AST, and run the code safely in its isolated sandbox.

Since I am juggling several projects right now, these security layers are still in their early stages that’s why I’m not publishing them currently… moreover I’m pretty sure Julia community have much more specialists on this matter.

4

This looks great!