I'm working on what is effectively a fork of prompt_toolkit [1], which supports many modern terminal features I needed for euporie [2], such as terminal graphics, extra text styles, color palette detection, terminal clipboard, synchronized outputs, CSI-u, mouse pixel positioning, etc.
I'd be very interested to test it's performance and to read your code (I'm not an AI, promise :)
> is there a way to swap the jupyter kernel within euphorie to something else more minimalist?
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.
I'm specifically interested in querying for support of particular glyphs (e.g. the symbols for legacy computing block), so applications can use a different fallback if it is know that a particular glyph cannot be rendered and will break the interface.
I agree that the addition of sending custom glyphs to the terminal is potentially problematic.
It's very interesting to learn about the newly proposed glyph protocol [1] in the linked blog post.
I was bemoaning the lack of exactly this here about 6 months ago [2]!
No evolution necessary! With my project, euporie [1], you can have use your data science notebooks with graphical image outputs, HTML, LaTeX, etc, all in the terminal.
Modshim does more than just wrap the external API of a package - it allows you to tweak something internal to the module while leaving its interface alone, without having to re-implement most of the package in order to re-bind new versions of objects.
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.
This sounds like an ideal use case for modshim [0]
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.
I'd find it very useful to be able to query a terminal to see if it has font support for a given list of characters.
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.
It should in theory be possible to mount the new virtual package over the lower module - but I don't think works currently (I'll have to test this). Doing this would make modifications available globally like you describe.
Let me explain what inspired me to create modshim:
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!
I'm working on what is effectively a fork of prompt_toolkit [1], which supports many modern terminal features I needed for euporie [2], such as terminal graphics, extra text styles, color palette detection, terminal clipboard, synchronized outputs, CSI-u, mouse pixel positioning, etc.
I'd be very interested to test it's performance and to read your code (I'm not an AI, promise :)
[1] https://github.com/joouha/euporie/tree/dev/packages/apptk
[2] https://github.com/joouha/euporie