Address status of pylti1.3

[michaelwheeler]

Due to other time commitments, the maintainer of pylti1p3 is unable to maintain that library beyond occasional bugfixes. Since pylti1p3 is a crucial dependency of django-lti it's worth considering how to address this moving forward.

A few possibilities that have been raised:

• Asking the maintainer of pylti1p3 if he would be willing to transfer or share ownership
• Creating a fork of pylti1p3
• Pulling pylti1p3 code directly into django-lti

[lsloan]

These all sound like good solutions, in that order of preference, too.

pylti1p3 hasn't been updated for at least one and a half years. It's been a long time since the last bugfix.

If UMich (either @academic-innovation or @tl-its-umich-edu) has the cycles available to maintain the module, I'm sure other organizations that depend on it would be appreciative. Volunteering for ownership or maintaining a fork would accomplish that.

Pulling pylti1p3 code into django-lti would work, but UMich would miss an opportunity to give back to the open source community. That is, unless the pulling in would also allow others to use pylti1p3 from the django-lti package independent of the Django features. (IOW, like making a pylti1p3 fork with django-lti "grafted" onto it.)

[michaelwheeler]

Pulling pylti1p3 code into django-lti would work, but UMich would miss an opportunity to give back to the open source community. That is, unless the pulling in would also allow others to use pylti1p3 from the django-lti package independent of the Django features. (IOW, like making a pylti1p3 fork with django-lti "grafted" onto it.)

I think the long term goal under this scenario would be to gradually remove all of the parts of pylti1p3 that make it framework agnostic. I've found that building on top of abstractions like MessageLaunch, LaunchDataStorage, and ToolConf adds a lot of complexity to a Django specific library like django-lti, and I'd love to get the value that pylti1p3 provides without paying that cost 😅