[DEPR]: edx-proctoring-proctortrack

[kdmccormick]

Proposal Date

2025-03-05

Target Ticket Acceptance Date

2025-03-19

Target Removal Date // Named Release

2025-04-07 // in time for Teak

Rationale

• These packages (one Python package, one JS package) are specific to a paid vendor: Vereficient Proctortrack
• It is not clear from the repository how Open edX site operators are to use it.
• It hosted in personal GitHub repository for somebody that we have no contact with rather than the openedx org.
• The Python package has been installed into github.in for 1.5 years, in direct violation of the comments in that file. That is causing two problems:
  • It slows down image building for every single Open edX site operator.
  • It blocks improvements like PEP 508 adoption, which would give us the flexibility to use faster build tools like uv.
• The JS package is the only prod JS requirement being installed from github

Removal

BREAKING CHANGE: edx-proctoring-proctortrack will be removed from github.in and thus removed from edx-platform's base requirements.

BREAKING CHANGE: edx-proctoring-proctortrack will be removed from package.json

BREAKING CHANGE: Any edx-platform references that are dependent on these packages will also be removed.

Replacement

Site operators can install this package into their private requirements.

Deprecation

None

Migration

None

Additional Info

None

Task List

TBD

[kdmccormick]

Communicated: https://discuss.openedx.org/t/deprecation-removal-edx-proctoring-proctortrack/15168

[pdpinch]

MIT is a customer of Verificient Proctortrack. Is this repo necessary to use Proctortrack proctoring in open edX?

[UsamaSadiq]

Noticing the author's lack of response on this package for past one and a half year, I've decided to maintain a fork of this package in preparation for the upcoming Django 5.0 upgrade instead of requesting the author for maintenance again.
The github hash was used to have Django 4.2 support because the author didn't publish a new release despite multiple requests on the PR

I was going to create a separate issue to switch the dependency in edx-platform to my forked package but seems like it can be discussed here.

[kdmccormick]

Great question @pdpinch . I think the answer is yes. @michaelroytman , would you be able to confirm or deny that?

Thanks @UsamaSadiq . If this package must remain in edx-platform for some reason, then we'll want to move your fork into the openedx org and publish it to pypi. On the other hand, if this package could be converted to an optional requirement, that would be ideal. In this case, we could either (1) find a maintainer for it and move it into the openedx org anyway, or (2) allow operators like MIT ODL and 2U to maintain their own forks of the package.

[michaelroytman]

Thanks for the ping! A few thoughts...

• Yes, the installation of the edx-proctoring-proctortrack library must be maintained in order for the Proctortrack proctoring integration to continue to function on the edX platform. My team is planning to privately install this library into our deployment of Open edX so that this feature continues to function properly.
• Yes, any Open edX deployments that rely on this library - doubtful - would need to install this library into their deployment.
• The edx-proctoring-proctortrack library is maintained by Verificient, the company that owns Proctortrack. This library is owned by them because we wanted for them to maintain ownership and make changes as needed. However, if we're getting limited support from Verificient in keeping that library up-to-date, then I think an edX-owned fork that they could make pull requests against as needed is reasonable.
  • We should inform Verificient of this change first to get their thoughts.
  • Can we keep the transition to this fork on the edX platform as a separate initiative? It will make handling this
    deprecation more challenging for us if we pair this work together.

A few questions for you, @kdmccormick.

• When do you anticipate removing this dependency? On 03/19/2025, provided there are no objections? We'd want to be sure to privately install and deploy this library before you remove the dependency.
• This library is also installed as an npm dependency. Will this be removed as well?
• I believe our plans to do a private installation are straight forward, and I don't anticipate any issues. We will test thoroughly. However, in the worst case scenario, could we revert the change temporarily?

[kdmccormick]

@pdpinch Does MIT ODL rely on Proctortrack only for edX.org courses, or do any of your own instances use it as well?

@michaelroytman , thanks for your quick response.

Can we keep the transition to this fork on the edX platform as a separate initiative?

Sorry, I don't follow this question, can you be more specific about which initiatives you'd like to keep separate, and can you be specific as to whether you're referring to edX.org or edx-platform?

When do you anticipate removing this dependency? On 03/19/2025, provided there are no objections? We'd want to be sure to privately install and deploy this library before you remove the dependency.

On the removal date: April 5th Monday April 7th. I just updated the ticket to be more clear on that.

This library is also installed as an npm dependency. Will this be removed as well?

Yes, great call out. I'll update the ticket.

I believe our plans to do a private installation are straight forward, and I don't anticipate any issues. We will test thoroughly. However, in the worst case scenario, could we revert the change temporarily?

I'd like this removed on April 7th so that we can capitalize on the build improvements for Teak (which is cut on April 9th), so I'd rather not revert after that point. But, if we did the initial removal a week or two earlier, then that would save us time for reverts and iteration from 2U. Looking at Mondays, we could first attempt the removal on 3/24 or 3/31. Let me know if you'd like to do that (or any other particular date before the 7th), and I'm happy to update the ticket.

[michaelroytman]

Sorry, I don't follow this question, can you be more specific about which initiatives you'd like to keep separate, and can you be specific as to whether you're referring to edX.org or edx-platform?

Ah, sorry for the confusion. I was referring to @UsamaSadiq's comment about using a fork of that repository instead of the current repository. I don't think that impacts you or this ticket.

I'd like this removed on April 7th so that we can capitalize on the build improvements for Teak (which is cut on April 9th), so I'd rather not revert after that point. But, if we did the initial removal a week or two earlier, then that would save us time for reverts and iteration from 2U. Looking at Mondays, we could first attempt the removal on 3/24 or 3/31. Let me know if you'd like to do that (or any other particular date before the 7th), and I'm happy to update the ticket.

Got it. Let me chat with the team and get back to you sometime tomorrow!

[michaelroytman]

@kdmccormick Also, is there support for installing npm modules into the edx-platform privately so that we can maintain the installation of this module in our deployment?

[kdmccormick]

@michaelroytman In terms of the edx-platform repo itself, there is no explicit support for private Python packages or private NPM modules. That's all operator-side stuff. I believe edx.org installs private Python packges by some overriding some EDXAPP_... Ansible variable in your edx/configuration repo. If there is no corresponding variable for NPM modules, then it should be possible for you folks to implement one using the same pattern that you use for private Python packages, just with npm install instead of pip install.

^ Heads up to @blarghmatey , if you've never installed private NPM packages into edx-platform, your mitodl deployment scripts might need the same minor enhancement.

Tutor sites will be able to handle this by writing a plugin which patches the Dockerfile to add an npm install .... statement.

[blarghmatey]

Thanks for the mention for visibility. We can easily add custom build steps into our deployments, we already do that for our Python packages.

[michaelroytman]

@kdmccormick, could you clarify what the following statement encompasses?

BREAKING CHANGE: Any edx-platform references that are dependent on these packages will also be removed.

Are we talking about things like imports from these packages or also references to Proctortrack as a proctoring provider? There are references to Proctortrack as a provider in a few places in the platform, and I'd like to make sure those are not a part of this deprecation.

Thanks!

[kdmccormick]

The intent is indeed to remove those references from edx-platform. The core platform will not support Proctortrack, so my sense is that it should not have references to Proctortrack.

If you feel that they should stay, can you help me understand why?

[michaelroytman]

@kdmccormick At what point do you think a pull request be ready to review? It would be a lot easier for me to determine what changes we need to make on our end with a full understanding of what will be removed.

I can't justify keeping Proctortrack-specific code in the platform, but I'm concerned about the conditional logic that's sprinkled throughout the platform that depends on the proctoring provider being proctortrack. I can follow up next week once I've had a chance to dig into it some more.

Have a good weekend!

[kdmccormick]

@michaelroytman I have a stretch goal of having a PR ready in the next two weeks in order to make the Teak cutoff. I'll try to do that, but no guarantee.

An alternative would be that if Cosmonauts could take this on, I'd be happy to delay this DEPR, as long as the full removal landed before the Ulmo cutoff (October 9, 2025).

[schenedx]

@kdmccormick
I understand the end goal of this work is to remove non-2U specific vendors, logic and references out of openedX code. The complete encapsulation and separation would take time and effort to address because how intertwined the logic was built in the beginning. I know you offered to extend the deadline of this goal to next openedX release. That said, I think we should be agile delivering this work by capturing deliverable steps towards the end goal.

My proposal is: let's stick with the title of this work to only turning the edx-proctoring-proctortrack library from a public dependency to a 2U private dependency. This is complicated enough because the dependencies to change are on both python library installation, and NPM installation for frontend javascript.

We would need another deprecation effort/issue to completely get rid of specific installed vendor like Proctortrack. The work involved will be:

• Proctortrack has custom logic such as studio email field and email templates
• Remove translation related to Proctortrack UI
• Remove unit test specific to Proctortrack
• Remove examples that reference Proctortrack.

This second step would need to be done on both openedx/edx-platform and openedx/edx-proctoring repos.

[kdmccormick]

@schenedx I understand that there will be some work involved in extracting proctortrack logic from edx-platform. Leaving proctortrack in edx-platform is not work-free either: the code incurs maintenance burden on the community and complicates ongoing efforts such as the removal of legacy LMS edx-frontends.

We can do this deprecation in two steps as you propose, but keep in mind that the intermediate state (edx-proctoring-proctortrack is private, but there is proctortrack code in edx-platform) leaves the edx-platform proctortrack code un-testable by the community, so regression becomes more likely. In order to make edx-proctoring-proctortrack, we may need to remove some of the edx-platform unit tests anyway.

Assuming we archive edx-proctoring-proctortrack in Teak, what timeline would you propose for removal of the code from edx-platform?

[michaelroytman]

Hi, @kdmccormick. Apologies for the delayed response.

If you are still planning to cut the Teak release in several days, the team cannot accommodate the full removal of Proctortrack in time, especially without a plan or pull request to review. We have much less capacity right now than we did several weeks ago, unfortunately.

I believe we can accommodate the removal of the edx-proctoring-proctortrack package from edx-platform, but I need an updated estimate of when this removal is planned to be merged. We'll have to do significant testing, so this would help me confirm whether we can manage the removal of the package.

Regarding the removal of all Proctortrack related code from the platform, I understand we have two options.

1. perform the removal at a later date, to be determined
2. delay the removal of both the package and the code until October 9, 2025 at the latest in exchange for our team doing the work

In either case, it would be really helpful for you to specify a set of requirements for the removal so I can understand the scale and approximate the work involved. What is it that you want removed? Is this just for edx-platform? Should we grep for proctortrack everywhere and remove those references? Something else?

Thank you.

[kdmccormick]

No worries @michaelroytman

The Teak cut is now planned for 23 April.

Here is a PR to remove proctortrack as a privately-installed requirement. I haven't tested it with mockprock yet, but I believe the code is complete: #36503

To echo your understanding, I'd like to either:

1. Merge that PR on Monday 4/21. Then, proceed myself with removing edx-platform proctortrack references when I have time.
2. Have 2U's agreement that they will remove both the proctortrack package and the edx-platform references at their own pace, as long as it's done by 9 Oct for Ulmo.

In either case, it would be really helpful for you to specify a set of requirements for the removal so I can understand the scale and approximate the work involved. What is it that you want removed? Is this just for edx-platform? Should we grep for proctortrack everywhere and remove those references? Something else?

We need it to be the case that no code in the openedx GitHub organization has any knowledge of or dependency upon Proctortrack or Proctortrack-specific concepts, with the exception of perhaps test code in the edx-proctoring package. That's about as specific I can get without starting to do the work myself.

[michaelroytman]

@kdmccormick Thanks! That's very helpful. I'll check in with my team tomorrow morning with this information and get back to you by the end of the week at the latest.

If we go with option 1, when do you think you'd be ready to merge in that second pull request? I assume it would be after the Teak cut? If possible, it would be helpful to know approximately how much time we'd have between April 21st and the removal of those lingering Proctortrack references so we can decide if option 1 is a better option.

[kdmccormick]

@michaelroytman Np. Yes, I'd aim for full removal between the Teak and Ulmo cuts, probably June at the earliest.

[michaelroytman]

Hi, @kdmccormick. The team would like to do discovery on all the ways Proctortrack is integrated into the platform so that we can better estimate the work involved and reach a decision on who does what. We estimate we'll need around two weeks for that. Afterwards, we'd share our findings with you. We'd like to collaborate on determining who does what and when. Please let me know what you think of that plan. Thanks!

[kdmccormick]

That sounds good to me @michaelroytman . Thanks! I'll hold off on any removal for the time being.

If you do manage to discover by the 23rd that it is safe to remove the editable package install, kindly approve #36503 so that we can get the build time improvement shipped out with Teak.

[michaelroytman]

@kdmccormick Where would you like me to put my findings and recommendation so that we can review and discuss? I assume in this DEPR? It's a bit of a long document, which is why I ask. Thanks!

[kdmccormick]

How about you make a public wiki page or google doc and link it here?

[michaelroytman]

All set. I've included a link to the Google doc below. Please let me know what you think. Thanks!

https://docs.google.com/document/d/17-J1Nc15MkLLvv5sG6QIoQgj_Z1Lml2YHOiQIZI8XPQ/edit?usp=sharing