Possibly include in SymPy about latex2sympy HOT 10 OPEN

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.

from latex2sympy.

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

from latex2sympy.

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.

from latex2sympy.

Any updates on this?
@augustt198

from latex2sympy.

Any updates @augustt198?

from latex2sympy.

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

from latex2sympy.

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.

from latex2sympy.

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

from latex2sympy.

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.

from latex2sympy.

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, #33, but whatever
  • make python3 ready (also on #33 and @jackatbancast's fork)
• docs
  • rtd
  • notebook examples
• test
  • break out tests (done on #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!

from latex2sympy.