News for hackers. Stuff that matters.
Re:Thoughts on the Python Packaging Ecosystem by lmm on Saturday January 21, 2023 @07:26PM (#34472605)
Shipping with python is a disadvantage; any real workflow tool needs to be able to manage multiple python installations, and if you try to use a part of the python installation to do that you've got a circular dependency problem. Plus the whole "where modules go to die" thing.
Re:Thoughts on the Python Packaging Ecosystem by solarkraft on Saturday January 21, 2023 @08:23PM (#34473042)
Does anything speak against flipping the relationship? i.e. using pip (or something else) as the standard way to install Python.
Re:Thoughts on the Python Packaging Ecosystem by cdogl on Sunday January 22, 2023 @01:14AM (#34474869)
pip is a python program.
Re:Thoughts on the Python Packaging Ecosystem by qbasic_forever on Sunday January 22, 2023 @01:20AM (#34474908)
You might want to look at micromamba as a separate tool that can install python itself, libraries, etc. with zero dependency on a python being installed. It's a very fast tool written in C++ so it's easy to install and use almost anywhere. It uses the conda ecosystem of packages.
Re:Thoughts on the Python Packaging Ecosystem by LtWorf on Saturday January 21, 2023 @08:45PM (#34473205)
If you have multiple versions of python installed you can just do

python3.9 -m pip

python3.10 -m pip

The standard library is the reason why python is popular to begin with.

Re:Thoughts on the Python Packaging Ecosystem by Hackbraten on Sunday January 22, 2023 @10:00AM (#34477966)
To me, that’d be a UX nightmare. Even if I tried to, I’m not going to memorize which of my 20 checked-out Python projects are requiring which Python invocation.

IMHO it’s absolutely the toolchain’s job to manage that for me. I’d never adopt a toolchain that wouldn’t.

Re:Thoughts on the Python Packaging Ecosystem by LtWorf on Sunday January 22, 2023 @03:38PM (#34481972)
You do know that python is backwards compatible right?

You can just use 3.11 with everything.

Re:Thoughts on the Python Packaging Ecosystem by lmm on Sunday January 22, 2023 @05:22PM (#34482876)
Traditionally it wasn't, and even a "minor" upgrade was a significant undertaking for a large project. Maybe that's changed.
Re:Thoughts on the Python Packaging Ecosystem by mattbillenstein on Sunday January 22, 2023 @06:05PM (#34483295)
Maybe in the 2.4 -> 2.7 transitions - Python3 after about 3.6 is pretty good, you might see some minor package breakage if you're running the very latest version, but that's fairly rare.

Generally speaking, if you're on a modern OS - like recent Ubuntu LTS or MacOS you're getting 3.8 -> 3.10 and compatibility is very good in these releases.

Re:Thoughts on the Python Packaging Ecosystem by acdha on Sunday January 22, 2023 @06:12PM (#34483374)
When exactly are you defining as “traditional”? The Python point releases have generally been painless for a long time. There was a little friction in the early 2-3 era before they made it easier to write code which worked on both without translation but in general it’s been at least a decade since I’ve cared about this except for one time where a couple of libraries depended on a private API which changed in Python 2.7.9, and that was back in 2014.

https://bugs.python.org/issue22438

Re:Thoughts on the Python Packaging Ecosystem by Hackbraten on Saturday January 28, 2023 @08:40AM (#34557486)
If my project is a library that needs to support e.g. 3.8 through 3.11, then I’m not going to use 3.11 for my development environment.

The same goes if my project depends on a library or framework that doesn’t support 3.11.