Possibly include in SymPy

[moorepants]

Your software solves a longstanding issue in SymPy:

sympy/sympy#5418

and is something that we'd really like to be included in SymPy.

Would you be interested in adding this to SymPy instead of having a standalone package? It'd certainly increase the usage and visibility.

[augustt198]

Sounds great, I'd love to add this to SymPy! Should I create a pull request?

[moorepants]

Yes, you can create a pull request, but it may be good to open a discussion on the mailing list first. Since this depends on ANTLR we'd need to discuss making it an optional dependency.

[hiamandeep]

Any updates on this?
@augustt198

[langston-barrett]

Any updates @augustt198?

[ferret-guy]

What if the package was distributed pre built? that would remove the ANTLR dependency for normal use.

[moorepants]

One option would be to build ANTLR for conda on conda forge (may already be there) and then we can utilize this package as an optional dependency for sympy. It would make the installation relatively painless.

[ferret-guy]

It actually is in conda forge, https://github.com/conda-forge/antlr-feedstock

[nicodjimenez]

Another option is to just include the python antrl runtime library as a hard dependency dependency in sympy, and just put the built parser binary in the repo, then antrl itself would be a dev dependency. In any case, for latex2sympy to be included inside sympy, someone inside the sympy community will have to shoulder the burden or it's never going to happen.

[bollwyvl]

Hey folks, over on #33, I've got a POC of packaging this repo, antlr4, and its runtimes in conda-forge-compatible recipes (not PR'd yet, for various reasons). Looks good, even on windows! Also started playing with a binder:

https://mybinder.org/v2/gh/bollwyvl/latex2sympy-demo/master

I also had a look around the community surrounding this repo, and had noticed that it is both stagnating and fragmenting, which seems unfair to the good work it already represents.

Doing a dive through various things, it seems like there are a few (not mutually exclusive) options:

• roadmap (is this one?)
• get healthy
  • bring it into sympy
  • get some more maintainers
  • start contributing to an existing fork
    • @jackatbancast has already taken the plunge and released
  • fork this (perhaps into sympy org)
• package
  • ideally, Make installable with setup.py #33, but whatever
  • make python3 ready (also on Make installable with setup.py #33 and @jackatbancast's fork)
• docs
  • rtd
  • notebook examples
• test
  • break out tests (done on Make installable with setup.py #33)
  • CI with travis/circle/appveyor
  • grow library of tests (e.g. fixtures, include docs)
• deal with (perceived?) antlr resistance
  • get an updated antlr/runtime more easily accessible for users, developers and CI
  • adopt another non-python parser chain (lex/yacc? bison?)
  • adopt a pure-python engine/generator/runtime
    • decision could be made on, say, in rough order of importance:
      • fitness for other parsed things (mathematica, maxima, sympyify) (if brought into sympy directly)
      • end-usability (e.g. error messages, robustness)
      • adoptability (e.g. dependencies? py3? pypi? crossplatform? pypy? anaconda/conda-forge?)
      • extensibility (i.e. can it be extended by a third-party entry_point or something for special interpretations without putting the burden on the end user)
      • performance (e.g. parse time, memory consumption, (maybe) code generation time)
      • productivity (e.g. ease of adding new grammar terms and python actions, inspectability)
      • popularity (e.g. downstreams, stars, forks, contributors, open prs, issues)
    • candidates:
      • arpeggio
      • lark
      • parsiminous
      • ply: in anaconda
      • pyparsing: in anaconda, upstream mathematica issue
      • pypeg
      • textx

I might not be the coder that does this, but am excited to help in any way i can!

[moorepants]

All sounds good. I just want to mention that we get lots of requests for this functionality in the sympy communication channels and that if it were part of sympy (with antrl as a optional dep) then the maintenance gets wrapped into sympy's flow which has advantages that I think outweigh those related to having a separate project.