Generally speaking, snaps aren’t a good format for allowing users to make changes to the bundled packages (they’re designed to be immutable). However if the package is likely to benefit the average university student and the license & technical requirements allow, I’d be happy to consider adding new packages to be included properly.
For a truly custom Python experience however, I’d recommend trying to rebuild the snap with a modified Python package list. The build environment should be fairly easy to set up, and you’d generate a file for yourself that you’re free to share with others and would never automatically update any of the bundled packages unless you rebuilt it and reinstalled it manually.
But aside from that, you can still instruct Python to look elsewhere for packages, including locations that are writable, and the snap still ships with Pip, which means you can do something like this:
root-framework.run pip3 install torch -t $HOME/pyroot-extras
You could then use the packages in that folder by prepending pyroot scripts with
The issue with this approach is that the Python environment may still change as the snap receives updates, e.g, there’ll be an update later this year from Python 3.8 --> 3.10, and you’d be responsible for setting up that folder again manually since it wouldn’t be included in the snap itself and would presumably break when that happens.
However, I might make some wrappers/changes (e.g, to the default
$PYTHONPATH variable) which might make that easier. But as is, the majority of the target audience doesn’t appear to mind the status quo, which makes this a relatively low priority.