Jupyter_contrib_nbextensions: Does this package actually require a specific lxml version?

[codypiersall]

In the setup.py, the version of lxml is tied to >=3.8.0. I need to run jupyter_contrib_nbextensions on an embedded ARM computer where I built a kernel using Yocto and the version of Yocto I'm using only supplies lxml 3.6.4. It's not trivial to build lxml 3.8+ on my PC.

Does this package really need lxml 3.8 or greater? I cloned this repo and installed it after removing the version requirement, and everything installed correctly and all the tests passed.

I'm happy to submit a PR, but before I did I wanted to see if I was missing something. If nbextensions really needs lxml >= 3.8, I'll just pin down the version of nbextensions in my own setup.py, but it'd be nice not to need to.

[jcb91]

I must admit that I don't really know! The only thing in the repo using lxml is the embedhtml exporter, but from a cursory glance at the usage and changelog, I'm unsure which would be the minimal required version. I suspect https://github.com/lxml/lxml/pull/233 (added for 3.8) might be relevant, but as mentioned, I'm unsure. Perhaps @gabyx has a better idea?

[jcb91]

Also curious @codypiersall, what's the usage case here, if that's something you're able to divulge? :)

[codypiersall]

Thanks for the quick responses @jcb91!

From the PR you linked to in lxml it looks like the fromstring() method got modified to be able to accept bytes _or_ str, and it "does the right thing." The only usage I found of lxml in nbextension is when converting the notebook to html. I'm not sure what the type of output is at this line. Probably a str at this point? I'm on a different computer so I can't check at this point. If it is a str, then the lxml version being less than 3.8. If it's a str or bytes, we could do the check before calling et.fromstring().

After we get some more feedback, I'd be happy to submit a PR that makes the version dependency on lxml go away one way or another.

I'm happy to talk about my use case! I work for the Advanced Radar Research Center, and the goal of the project I am working on now is to create a low-cost radar with easily available components. I am using a Jupyter notebook to present a user interface to control the radar. The brain of the radar is a Zynq, which is a chip that has a dual core ARM processor and an FPGA. Ultimately, the notebook runs on that chip, and the user connects to the notebook to configure the radar and make it go. I'm not using many things in nbextensions, but codefolding makes my life so much better I'd rather not give it up.

I can give more information about what I'm doing if you want!

[gabyx]

This is sofar the only use case, correct. I am not sure, but I think it is a str.
Try to use a lower version, make a PR and we will see if the test run through. I think positive :-)

[codypiersall]

PR sent! #1174

[jcb91]

Ah that sounds awesome @codypiersall :smile: thanks for the explanation! Where are you envisaging your low-cost radar units be used? I've not come across the zynq before but that also looks pretty neat!

[jcb91]

should be fixed by #1174, but will leave this open until a release is made including it

[codypiersall]

@jcb91 Thanks! Yeah, the goal is to have a low-cost radar. The Zynq is a really neat little chip. Jupyter notebooks and this project made the UI development much less painful and look better than I would have been able to do otherwise, so I really appreciate this project!

[jcb91]

closing this now that 0.4.0 is out