Should we ship the code for optional extension modules? #6
Replies: 3 comments 10 replies
-
|
I think this is basically a requirement to make this distribution palatable/of interest to users if we expect it to be used by consumers and not just a build to be re-packaged. A lot of things break if you don't ship at least OpenSSL and zlib. And a lot of software is written with common optional modules expected to be present (whether they should or not is a different story). I think another related question is: What do we do if there is a CVE in a dependency? Are we going to need to release more patch releases to handle CVEs in dependencies? The process there seems complicated and would be good to flesh out. |
Beta Was this translation helpful? Give feedback.
-
|
I think there's a strong argument for "both" (i.e. two different packages). There's plenty of useful application for a Python runtime that doesn't have that functionality at all, and that's typically a case where it needs to be more relocatable. It seems okay to assume that users who choose this "minimal" runtime (the "embeddable distro", in terms of existing releases1) may have other ways to get modules. So they can get the ones they need - Footnotes
|
Beta Was this translation helpful? Give feedback.
-
|
+1 the idea that modules like OpenSSL and SQLite need to be present or many users are going to be very surprised. However, I wonder if revisiting the "minimal viable Python" idea might be worthwhile in this context. If the binary artefact is a "minimal" Python, but it's possible to I appreciate that MVPy efforts haven't been very successful in the past (for a variety of reason); but I figured that it's worth mentioning given the overlap of concerns that exists with optional (and especially optional binary) extension modules. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
E.g. do we ship OpenSSL, zlib, SQLite, etc.?
Beta Was this translation helpful? Give feedback.
All reactions