On Fri, May 10, 2024 at 04:42:49PM +0200, Ralf Gommers wrote: > It gets ever-easier to install new Python versions, with pyenv/conda/etc. The > "my single Python install comes from python.org and I'm using the same one > because I am afraid to upgrade" is much less of an issue than it was 10 years > ago. And it's caused mostly by users having knowledge gaps. So yes it can be > a pain for them, but they'll have to learn at some point anyway. Same for "my > old HPC cluster uses ..." - it's often an even older Python anyway, and > you'll have tons of reasons why you don't want your cluster-installed stack - > learn to use Spack or Conda, and you'll be much happier in the long run.
IMHO the view that its a tooling/knowledge gap problem is a bit disconnected of users. I meet many users who either 1. cannot control the Python version they run, or even the base environment, because of company culture (decisions at company level on these constraints). Maybe upper management in completely misguided here, but then upper management must be targeted, and it is not clear at all that constraints on packages is the right way to do it, as they typically never run any code. 2. have environments with many dependencies that get in gridlocks of dependencies that cannot be mutually satisfied. For my own work it becomes increasingly frequent for me to spawn multiple environments that then talk to each others (eg via files) to work around these problems. Problem 1 is probably something that user organizations should change, and we need to understand why they lock Python versions. It could be a QA issue, and this might reveal both a lack of good practices for QA (ie testing) but also the instability of the ecosystems that creates a fear of upgrade. We should not be too fast in dismissing these organizations as strife with bad practices that could easily be changed, as even tech-savy organizations (such as Google, I believe) run into these problems. Problem 2 is not a problem solvable by users: it comes from the fact that dependency version windows are too narrow. Without broad windows on dependencies, the more dependencies one has, the more one gets into an impossible situation. For this last reason, I strongly advocate that packages, in particular core packages, try hard to be as permissible as reasonably possible on dependencies. Cheers, Gaël _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
