Mess is freedom. It gives many choices.
Python: Please stop screwing over Linux distros
351–360 of 384 posts
Re: Python: Please stop screwing over Linux distros
#352Earlier quoted context omitted.
> Perhaps the distributions would be more inclined to include up-to-date version if the standard in the python community was not to break everything all the time. Yep... Perl is a godsend... take a code from 20 years ago, run it on a modern system, and everything works. Python? Three different software versions need three different versions of the same library, and new library versions are not backwards compatible wi…
Perl 4, 5, or 6? What's CPAN's dependency resolution like?
That's a really weak gotcha: Perl 4 was deprecated 28 years ago and Perl 6 is a completely different language that's been called Raku since 2019. There are no dependencies to resolve between them. It's like worry about dependency resolution between Javascript and Java. They're not even the same platform.
Re: Python: Please stop screwing over Linux distros
#353Earlier quoted context omitted.
> Everyone complained, no one addressed the fact that for years the whole of python packaging was handled by like 2.5 people. If I can make an observation - it has nothing to do with the number of maintainers. The problem is deep, cultural and occupies a difficult space where it might be a bug or a feature. The root cause here is that the Python project, and surrounding community, have little real respect for backwar…
Python 2 was supported for 20 years . Python 2.7 (largely compatible with other Python 2 versions - and including backported changes from Python 3.1 - was supported for 12 years ). The Python project went absolutely above and beyond to support users who wanted to drag out making not particularly complex changes to their codebase for over a decade . During this same time they improved Python 3 in response to feedback…
Yes. That is what a culture of not supporting backwards compatibility looks like. If they valued backwards compatibility they wouldn't have to support multiple versions of Python over long stretches of time. They would be supporting 1 version that was backwards compatible with code written over 20 years ago.
Re: Python: Please stop screwing over Linux distros
#354Earlier quoted context omitted.
"Thou shalt not mess with the system Python"
Given, and yes I've heard that before, but I counter with: If you don't want someone to mess with it, name it as something other people will not regularly have a reason to muck with. One concerted effort to ship distro's with a "sys-python" symlink instead of /usr/bin/python, and for all things currently using the newly minted sys-python stuff can be free of wayward travelers and system sculptors like me mucking with…
> No, pyenv is not the answer. Naming things is.
In my experience, Pyenv is almost never the answer.
Re: Python: Please stop screwing over Linux distros
#355Earlier quoted context omitted.
This is actually where a BDFL should step in. "We're doing X for Python 5, we're using it to manage the stdlib as well as community packages, everyone get ready because I have decided."
They tried this with pip. Distros ripped it out. They added the ensurepip module so users could add it after the fact. Distros ripped it out too. Arguably the advantage newer languages like Rust and Go have in this regard is they don't even consider the distro use case - you're going to get static linking and you'd better like it. Whereas Python is from an older era and tries to fit in with the local customs and so g…
Yes, and that's fine. Distro python isn't for end users.
Re: Python: Please stop screwing over Linux distros
#356>I What is it about Linux distros that makes our use-case unimportant? Have we offered no value to Python over the past 30 years? Do you just feel that it’s time to shrug off the “legacy” systems we represent and embrace the brave new world of serverless cloud-scale regulation-arbitrage move-fast-and-break-things culture of the techbro startup?* The thing is, people in development wont use the distro python (but diff…
Many system applications are written in python. For example, the package manager for my system (dnf) is written in python.
That just requires one, mostly fixed, version of Python. It's a system dependency, not something the end users of the distro should be concerned with.
Re: Python: Please stop screwing over Linux distros
#357Earlier quoted context omitted.
> You realize that if that was "impossible" and "never happening", then absolutely no Python environment would be working ever? No, it means that you can't be fully sure that upgrading everything to the latest version is not going to break anything. And right now, you can't. You can only do that in controlled environments (say, a distro's official package repositories), not with Python packages. > Please don't make t…
> you can't be fully sure that upgrading everything to the latest version is not going to break anything. Well, it's still what you do every time you create a new project. > It is mandatory in quite a lot of package managers. Ok but many packages won't be installable at all anymore, because people pin different versions instead of maintaining their packages by continuously integrating upstream releases. > You can't l…
> Well, it's still what you do every time you create a new project.
Yep, and it is a pain in the ass when the package you want to use creates a dependency conflict. Luckily, at that stage I can still search for an alternative with little to no cost.
> Ok but many packages won't be installable at all anymore, because people pin different versions instead of maintaining their packages by continuously integrating upstream releases.
And some packages won't be installable anymore because they use deprecated APIs, or were only compatible with Python 2, or expected certain files/folders/programs to be present on the system and they aren't anymore. Packages go into abandonware all the time, removing version pinning doesn't fix that.
> Instead, you should be upgrading your code to support the newer numpy version. Seriously, try it out, you'll be spending less effort at the end of the year.
Thank you for telling me this, I will be relaying to my clients that they need to upgrade their systems to newer Python versions to get new features, surely that will go well.
> I wait for CI or users to report that a new release isn't compatible so I can fix it as soon as possible, in which case we temporarily pin versions, instead of piling up tech debt until it's so huge the whole project becomes trash.
Well, I prefer to not have my program crashing in client environments because someone decided to update a package and break things.
> piling up tech debt until it's so huge the whole project becomes trash.
Waiting to release on new dependency versions until those versions are tested is not tech debt. I mean, semantic versioning was done with this purpose precisely: to signal which upgrades are just bug fixes and you should upgrade ASAP, which ones are new features so you can upgrade without too many problems, and which upgrades break compatibility and you should test it thoroughly in case something broke.
If living at latest release works for you and dealing with dependency issues on new installations is not a problem, then go. But other systems will require that a certain release installs dependencies on a consistent manner. Some of my dependencies are automatically upgraded and tested before release, others are pinned because they always break things and I only upgrade manually. But once a version of a package is released, that one goes with version pinning because I prefer to avoid the risk of a client installing the software and having to explain them than "oh, it's just that this dependency released a new version that broke things and we didn't specify the version that our software needed".
Re: Python: Please stop screwing over Linux distros
#358Earlier quoted context omitted.
There are different cadences and roles in play here. Cadences: Distribution - e.g. Ubuntu 21.10, 22.04; RHEL 8.4, 8.5, ..., 9 Library - e.g. simplejson 3.17.4, 3.17.5, ..., 3.18.0 Language - e.g. Python 3.8.0, 3.9.0, 3.10.0 (This makes Python particularly annoying because for a C project it shouldn't matter if you used gcc 8 or gcc 9 when producing binaries, but with Python it very much matters which version of Pytho…
Wouldn't be better if the python programmers did a bit of planning ? Or are the things so boring that every python minor version must be incompatible with other python minor versions.
Features get added. So you can't use a match statement in 3.9 but you can in 3.10. If you write a library you need to be conservative in which features you use or applications can't use you.
Why not just upgrade applications ASAP? Sometimes things are removed over three or so versions. So you can't move from e.g. 3.9 to 3.10 without making sure you're importing types from the correct location:
https://docs.python.org/release/3.9.0/whatsnew/3.9.html
> Aliases to Abstract Base Classes in the collections module, like collections.Mapping alias to collections.abc.Mapping, are kept for one last release for backward compatibility. They will be removed from Python 3.10.
These things are planned. It's just much much harder to handle this because you need the interpreter at runtime while in compiled languages you just use `-std=C99` and you can compile the code and then link.
Re: Python: Please stop screwing over Linux distros
#359Earlier quoted context omitted.
Perl 4, 5, or 6? What's CPAN's dependency resolution like?
That's a really weak gotcha: Perl 4 was deprecated 28 years ago and Perl 6 is a completely different language that's been called Raku since 2019. There are no dependencies to resolve between them. It's like worry about dependency resolution between Javascript and Java. They're not even the same platform.
True. But Raku (https://raku.org #rakulang) does have an Inline::Perl5 module, which allows you to use 99.9% of modules on CPAN (basically, only the ones using source-filters, and ones that are really, really deep into the Perl internals). So there *can* be dependencies between Perl and Raku.
Re: Python: Please stop screwing over Linux distros
#360Earlier quoted context omitted.
Cargo started as a port of Ruby's Bundler. If Ruby can do it, Python certainly can.
Don't underestimate the culture differences between the Ruby and the Python communities. With Ruby, you are expected to update frequently. New ruby versions are eagerly awaited and all the major packages are updated pretty quickly.
Python is just a more fractured community, for reasons that have never really been that clear to me.
But it doesn't harm the point I was getting at, which is that being a dynamic language doesn't give Python an excuse compared to Rust in itself when there are highly successful adjacent examples. Obviously there are other factors that come into play, or it would be ancient history by now.