You can use euporie-console for a REPL-like terminal experience (still with rich outputs) if you don't want the full notebook experience.

You can also select the `local-python` kernel in euporie to run code using the local Python interpretor which runs euporie, instead of connecting to a Jupyter kernel.

> And when you run a project with ssh, there are ways to give access to other users with user:password if I may ask?

> I also wish to ask if there is a way to sign in to jupyter instance like that itself perhaps?

euporie-hub supports spawning notebook instances for connected users, but I haven't implemented collaborative editing like JupyterLab supports (yet). I believe that jpterm [1] might support this.

[1] https://github.com/davidbrochart/jpterm

I agree that the addition of sending custom glyphs to the terminal is potentially problematic.

[1] https://rapha.land/introducing-glyph-protocol-for-terminals/

[2] https://news.ycombinator.com/item?id=45805072

[1] https://github.com/joouha/euporie

There are a couple of example of this readme: (1) modifing the TextWrapper object but then use it through the textwrap library's wrap() function, and (2) modifing the requests Session object, but then just using the standard requests.get(). Without modshim (using standard monkey-patching) you would have to re-implement the wrap and get methods in order to bind the new TextWrapper / Session classes.

One of its intended use cases is bridging contribution gaps: while contributing upstream is ideal, maintainers may be slow to merge contributions for various reasons. Forking in response creates a permanent schism and a significant maintenance burden for what might be a small change. Modshim would allow you to create a new Python package containing only the fixes for your bugbears, while automatically inheriting the rest from upstream httpx.

[0] https://github.com/joouha/modshim

I use it as a fallback option for terminals without proper terminal graphics support in my TUI Jupyter client, euporie.

There are Python bindings available: https://github.com/GuardKenzie/chafa.py

It's akin to JupyterLite, providing a temporary online Python notebook environment without the need to install any Python packages. It's potentially useful if you need to do a bit of quick interactive work in Python, but don't have the environment set up ready to do so.

Since actual jupyter kernels can't run in pyodide (they run as subprocesses and communicate over ZMQ), it uses an in-process Python kernel which runs on the same interpreter as the application itself.

Notebooks and files can be saved persistently to a local-storage based file system. It uses xterm.js as the terminal emulator (though I'm keen to test out ghostty-web).

[1] https://news.ycombinator.com/item?id=27091167

Comments URL: https://news.ycombinator.com/item?id=46246017

Points: 3

# Comments: 2

This would allow TUIs to use recent unicode characters which may not be supported (e.g. Symbols for Legacy Computing), or private use characters (e.g. powerline symbols & font-awesome icons), while falling back to a more universally supported character in terminals that do not support them.

I've written a Jupyter client for the terminal (euporie), for which I've had to employ monkey-patching of various third-party packages to achieve my goals and avoid forking those packages. For example, I've added terminal graphics support & HTML/CSS rendering to prompt-toolkit (a Python TUI library), and I've changed aiohttp to not raise errors on non-200 http responses. These are things the upstream package maintainers do not want to maintain or will not implement, and likewise I do not want to maintain forks of these packages.

So far I've got away with monkey-patching, but recently I implemented a kernel for euporie which runs on the local interpreter (the same interpreter as the application itself). This means that my patches are exposed to the end user in a REPL, resulting in potentially unexpected behaviour for users when using certain 3rd party packages in Python through euporie. Modshim will allow me to keep my patched versions isolated from the end user.

Additionally, I would like to publish some of my patches to prompt_toolkit as a new package extending prompt_toolkit, as I think they would be useful to others building TUI applications. However, the changes required need to be deeply integrated to work, which would mean forking prompt_toolkit (something I'd like to avoid). modshim will make it possible for me to publish just my modifications.

Perhaps it's a somewhat niche use-case, and modshim is not something most Python users would ever need to use. I just thought it was something novel enough to be of interest to other HN users.

> messing around with import internals in python is extremely tricky to get right

This is true! modshim has been the most complicated thing I've written by some way!

It's a bit like OverlayFS for Python modules - it allows you write modifications for a target module (lower) in a new module (upper), and have these combined in a new virtual module (mount).

It works by rewriting imports using AST transformations, then running both the lower and upper module's code in the new Python module.

This prevents polluting the global namespace when monkey-patching, and means if you want to make changes to a third-party package, you don't have to take on the maintenance burden of forking, you can package and distribute just your changes.

Comments URL: https://news.ycombinator.com/item?id=45604013

Points: 109

# Comments: 30

[1] https://github.com/joouha/euporie

https://github.com/mintty/mintty/wiki/CtrlSeqs#overstrike