Should plbase and the Python grader use same requirements file?

[jonatanschroeder]

Currently the Python grader and the plbase image have separate requirements files. However, in some cases this can lead to some issues if a package is available in plbase (and thus in server.py files), but not in the grader. Would it make sense for the Python grader to use the requirements.txt file from plbase as a starting point, potentially adding a couple more as necessary? I didn't want to create an issue before some discussion about it.

[nwalters512]

Has this actually lead to issues in the past? In my mind the kind of code that's executed in server.py and in student code is different, so it's not entirely obvious to me that we'd want them to match closely. Maybe that's not true though.

My primary concern is image size. I'm hesitant to add packages "just in case" if it'll result in significantly larger images. If you'd like to advocate for this change, it'd be good to know how much larger our images would get if we did this.

[jonatanschroeder]

That's a good point, actually. I did a scan over some of the packages, and it includes some that may not be necessary in the grader context, such as rpy2 and the Python linters (flake, black, etc).

[eliotwrobson]

Definitely agree with Nate that not wanting to blow up the image size is important. Stuff like this actually comes up reasonably often however, since it's possible to use shared code between externally graded questions and non-externally graded questions, and this mismatch can lead to bugs that are hard to find.

[nwalters512]

If nothing else, we should ensure that versions that are present are consistent between all three. That should eliminate "this API works differently" problems and leave us with "this library isn't installed" problems which should at least be easy to identify.

[jonatanschroeder]

I assume by "all three" you mean including the Jupyter workspace, and in that case I agree with you. That said, I don't think the Jupyter workspace has dependabot set up... See #8698.