WeBWorK Main Forum

Removing OPL from server - any danger?

Removing OPL from server - any danger?

by Nathan Warkentin -
Number of replies: 5
I run an existing, small WeBWorK server for my high school. I upgraded to 2.16 this year and am implementing a course using TikZ in many problems. I am finding that it is generating more and larger temporary image files. This is not a problem in itself, but I am bumping up against the storage limits of my AWS instance, and it's too close for comfort.

Rather than run a more aggressive cron job to purge temporary files more often (or petition admin for more funding mid-year), I would just like to remove the vast bulk of the OPL problems sitting on the server. Almost all of the problems in our courses are written by me anyway, and I am gradually moving away from using OPL problems in any set at all.

My questions are these:
  • Will anything break if I just delete files in the OPL directory? I'm particularly eyeing /Contrib/UBC ...
  • Are there any server settings that I need to change so that WeBWorK no longer tracks local problems against the public directory?
In reply to Nathan Warkentin

Re: Removing OPL from server - any danger?

by Danny Glin -

The only thing that I would expect might break would be the Library Browser, and even then I don't think it would be anything more than "file not found" errors when you try to view problems.  You should be able to fix that by re-running OPL-update (From 2.17 onward you would need to run OPL-update-legacy if you are changing the contents of the OPL folder, since the new OPL update automatically grabs the latest version of the OPL).

You could do a test by moving one folder of the OPL somewhere else (i.e. outside of the /opt/webwork tree) and see if it breaks anything.  If things go horribly wrong you can always move it back.

If you are writing novel problems you should consider contributing them to the OPL.  They could be beneficial to the community, and the OPL is lacking in problems using some of the more recently added features (e.g. TikZ).


In reply to Danny Glin

Re: Removing OPL from server - any danger?

by Nathan Warkentin -
Danny and Andras, thank you both for your answers.

In response to your comments, Danny, about contributing to the OPL, it has certainly been on my mind. My work is busy, and I am still in the midst of implementing courses, so OPL contributions will not happen in the short term. However, the improvement upon my school's program since I started implementing WeBWorK in our courses has been substantial. I intend to give back to the project in whatever ways that I can.

Indeed, my main frustration with implementation has been the overall low quality of exercises in the OPL - I often come to regret using them in my problem sets. Contributing some of my work to the library seems a reasonable response.

One question as a follow-up, regarding contributions to the OPL. I have noticed that a number of problem authors in the OPL use macros hosted on their institution's servers to write problems. While this may work for very large, stable institutions. I work in a comparatively small international school, and it is not reasonable to assume that any macros hosted on one of our servers will persist for an extended period of time. I have a fairly large number of subroutines that I've developed to ease problem authoring and checking answers, and I store them in custom macros locally. What would be a best practice for publishing to the OPL in a circumstance like that?
In reply to Nathan Warkentin

Re: Removing OPL from server - any danger?

by Danny Glin -

Regarding macro files related to OPL problems, there is some work being done currently to clean this up.

One of the principles of the OPL is that submitted problems should be institution-agnostic (i.e. they should not have references to institution-specific resources), though this has not always been enforced.  Although macro files are sometimes named after an institution, the subroutines within them should be applicable outside of that institution.

Going forward the recommended practice will be something like the following:

  • Macros should not explicitly refer to anything relating to your institution.
  • All macros that are relevant to the community should be submitted to the PG repository and not the OPL.  If they are related to macros in existing files then they should be submitted as modifications to those files.  If they are a new class of macros then a new file can be created.

If you get to a point where you're ready to submit something you can open a pull request on Github, and the release team will provide feedback if things need to be moved around.

In reply to Danny Glin

Re: Removing OPL from server - any danger?

by Nathan Warkentin -

Thank you for the clarification, Danny. This is the kind of policy that I would expect - it is not sensible to have publicly available problems with components tied to a specific organization.

With respect to my own contributions, I am sure that some of my own subroutines have relatively sloppy implementations. A good example of this would be the logic that I use in checking that students have factored a polynomial correctly within a single answer blank. Although my code does its job well enough, I would be surprised if it was ready for inclusion in the repository. In this case, is it better to submit it in its extremely unpolished format or delay and find time to work on it later?

In reply to Nathan Warkentin

Re: Removing OPL from server - any danger?

by Andras Balogh -

I am helping some high schools with course templates and and in fact I regularly remove the library link from the template directories because in some specific courses it is more of a distraction, and we don't even want teachers to modify the assignments. This is the same as removing the actual libraries, since they stop being able to access them. It causes no problem at all.