How about instead we find a way to persist per-user installed packages?

Sure, but I thought it was simpler to pre-install a single package (provided it's useful for the thing I could expect to do with pywikibot). On the other hand, is there any way to install extra elements that are not installed though pip? I'm trying to read mdb files and the packages require additional support from the operating system (see this, for instance)

In T189503#4044958, @Discasto wrote:

Sure, but I thought it was simpler to pre-install a single package (provided it's useful for the thing I could expect to do with pywikibot).

To me it's doesn't seem to be one of those packages that a large proportion of PAWS users would use. Pre-installing packages just for a few users will cause our pool of packages-to-install to be very large (see T55704), and containerization (where every user's processes run in different containers (think of them as lightweight VMs, except the kernel is the same as the host kernel)) will not be able to handle so much usage (this was actually attempted for toolforge in T152089).

On the other hand, is there any way to install extra elements that are not installed though pip? I'm trying to read mdb files and the packages require additional support from the operating system (see this, for instance)

You are always free to compile C dependencies for your own tool / container / whatever in case your code runs on anywhere where you cannot use system package manager (this apply also to toolforge). The question is whether it should be officially supported; and if so whether the method should be documented and/or made easier.

For now, feel free to ask me in case you have trouble doing the compilation for C dependencies, I've done it on toolforge like half a dozen times for different reasons.

In T189503#4045224, @zhuyifei1999 wrote:

In T189503#4044958, @Discasto wrote:

Sure, but I thought it was simpler to pre-install a single package (provided it's useful for the thing I could expect to do with pywikibot).

To me it's doesn't seem to be one of those packages that a large proportion of PAWS users would use. Pre-installing packages just for a few users will cause our pool of packages-to-install to be very large (see T55704), and containerization (where every user's processes run in different containers (think of them as lightweight VMs, except the kernel is the same as the host kernel)) will not be able to handle so much usage (this was actually attempted for toolforge in T152089).

Well, in this specific case, mind that GeoJSON is the data type used in MediaWiki maps and in the Map Data namespace so, yes, GeoJSON is a quite sensible package to have in a pywikibot environment. However, I do agree a way to persist packages would be even better :-)