D1581: rust: implementation of `hg`

cramertj (Taylor Cramer) phabricator at mercurial-scm.org
Wed Jan 10 16:49:02 EST 2018


cramertj added a comment.


  In https://phab.mercurial-scm.org/D1581#31035, @indygreg wrote:
  
  > In https://phab.mercurial-scm.org/D1581#31029, @cramertj wrote:
  >
  > > There are a lot of uses of `unwrap`, `expect`, and `panic` that can (and probably should) be replaced with proper error handling using `Result` (and the `failure` crate).
  >
  >
  > I definitely agree. I still consider this just beyond proof-of-concept code. We'll definitely want to shore things up before we ship. Perfect is very much the enemy of good at this stage.
  >
  > > There are also a couple of crates that provide safe bindings to Python interpreters-- I'm not sure what your external dependency situation is, but you might consider using something like https://crates.io/crates/pyo3 rather than writing your own `unsafe` calls to the python interpreter.
  >
  > pyo3 requires non-stable Rust features last I checked. That makes it a non-starter for us at this time (since downstream packagers will insist on only using stable Rust).
  >
  > If other external dependencies provide the interfaces we need, I'm open to taking those dependencies. But this crate is focused on embedding a Python interpreter. Most (all?) of the Rust+Python crates I found seemed to target the "implementing Python extensions with Rust" use case, not embedding Python. As such, their embedding API support is very lacking. I even had to fork rust-cpython because it didn't implement the proper APIs and is forcing its extension-centric religion on consumers. I've upstreamed most of my modifications though. So hopefully the fork doesn't live much longer...
  
  
  SGTM! Thanks for clarifying.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1581

To: indygreg, #hg-reviewers, yuja
Cc: cramertj, yuja, quark, durin42, dlax, mercurial-devel


More information about the Mercurial-devel mailing list