Relationship with pylti/lti

[ryanhiebert]

As the current primary maintainer of pylti/lti, what is your thought about the relationship between this project and that project / organization? What is the key value that you're targeting here, and is there a collaboration that may be useful to both of us?

I would love to see others interested in improving the pylti/lti codebase. There are lots of things I don't like about it (I didn't write most of it), but I really haven't been able to give it much attention myself. I'd be happy to be a part of helping shepherd work there, or if it's better for everyone, here.

I'd appreciate your thoughts on where you'd like to see the state of LTI libraries in Python heading. Thank you for any feedback you can give.

[pdpinch]

Thanks for asking. As you have no doubt noticed, we don't give this library a lot of attention. However, it's a key library for faculty-written tools at MIT and the number of those tools is increasing. I expect that MITODL will be spending more time with this in the coming months.

The two major shortcomings with this library that I'm aware of is lack of Python 3 support and lack of Django support. Are there others?

When we wrote this library pytli/pylti didn't exist (as far as I know), so we didn't evaluate it. What are the differences between pylti/pylti and this library?

I believe Harvard has a python LTI library (or libraries) as well. The last time I checked, they lacked python 3 support as well and although they worked with django they didn't have Flask support. Flask has been particularly useful for our faculty coders.

[ryanhiebert]

The lti library (https://github.com/pylti/lti) is forked from dce_lti_py (From Harvard DCE), which itself was forked from ims_lti_py (Top Hat Monocle), and the folks that are behind those are members of that organization, though with similar participation as I've been giving to it, and that has been given as well to this library.

lti does use oauthlib, which IMO is a significant benefit to using it. I'm biased, though, I wrote the patch that added SignatureOnlyEndpoint to oauthlib. There is also a contributed Flask tool provider, though I haven't used it personally, and can't attest to its suitability for your purposes. lti is also Python 3 compatible, to the extent that it's tested (and if you find Python 3 bugs, I'll be happy to work on them).

What I'm hoping is that we can work together to try and avoid some duplication of labor, given the relatively small amount any of our libraries are getting, and hopefully have a bit more fault-tolerant maintainership. There are lots of improvements that can be made to lti, and the more actionable an issue, the more likely I am to jump in and fix it (just speaking for myself).

If we could find a way to merge these two libraries, I think that would be excellent, especially if in the process we can end up combining our small amounts of maintainer time to get something that is better maintained for us all.

I'm partial to the name of lti and the pylti organization, but really I'm wondering with this issue less about a name, and more about if a shared organization and/or library would be something that everyone would be on board with. If so, I'd like to see us compare the use-cases of both libraries, and see what a shared path forward might look like.

Is that something you're on board with looking at?

[ryanhiebert]

@pdpinch : Just wondering if you have any response to that. If it were me in your position, it's likely that a conversation like this might be abandoned not out of disinterest, but just because of distractions and scatterbrainedness, so I wanted to make sure that's not the case.

Of course, feel free to tell me that it's not a great time to look at a shared effort, that's perfectly appropriate too ;-)

[Ferdi]

@ryanhiebert the answer is yes, of course, we would like to collaborate. Any thoughts on how do we do that ?