On Wed, May 2, 2018, at 09:42, Gregory Szorc wrote: > The direction Mercurial is going in is that `hg` will likely become a Rust > binary (instead of a #!python script) that will use an embedded Python > interpreter. So we will have low-level control over the interpreter via the > C API. I'd also like to see us distribute a copy of Python in our official > builds. This will allow us to take various shortcuts, such as not having to > probe various sys.path entries since certain packages can only exist in one > place. I'd love to get to the state Google is at where they have > self-contained binaries with ELF sections containing Python modules. But > that requires a bit of very low-level hacking. We'll likely have a Rust > binary (that possibly static links libpython) and a separate JAR/zip-like > file containing resources. I'm curious about the rust binary. I can see that would give you startup time benefits similar to the ones you could get hacking the interpreter directly; e.g., you can use a zipfile for everything and not have site.py. But it seems like the Python-side wins would stop there. Is this all a prelude to incrementally rewriting hg in rust? (Mercuric oxide?)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4