Live data from Hacker News

Python: Please stop screwing over Linux distros

drewdevault.com

301–310 of 384 posts

Re: Python: Please stop screwing over Linux distros

#301
post #259
post #202

Earlier quoted context omitted.

And people will still be shipping code faster and more efficiently than they would do in Perl. Because in the end, the advantages of using Python, in terms of readability and productivity, easily offset a bit of packaging pain - whereas the disadvantages of using Perl don't offset whatever marginal gain you get by using old infrastructure.

And people will still be shipping code faster and more efficiently than they would do in Perl. I feel that quite a bit of software written these days is designed to have a short shelf life. I wonder how many of the "Show HN" posts will work, or even be useful, in five years? How much will be maintainable? I've been thinking a lot about Matthew Crawford's writings on mechanical things[0] and how they might apply to my…

> I feel that quite a bit of software written these days is designed to have a short shelf life. I wonder how many of the "Show HN" posts will work, or even be useful, in five years? How much will be maintainable?

Yep, all the python2 code from 5 years ago doesn't work anymore... It's sad how getting python2 to work on newish distros is becoming a great pain in the ass.

Re: Python: Please stop screwing over Linux distros

#302
post #97

Earlier 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. There are distributions that keep up-to-date, though, e.g., archlinux. Serving the needs of python developers vs. sysadmins is a false dichotomy. Python developers develop on a system that they need to admin. One great thing about linux is that everything on…

> 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?

Re: Python: Please stop screwing over Linux distros

#303

Earlier quoted context omitted.

So, Perl is the new Latin?

It can be: use Lingua::Romana::Perligata; adnota Illud Cribrum Eratothenis maximum tum val inquementum tum biguttam tum stadium egresso scribe. da meo maximo vestibulo perlegementum. maximum comementum tum novumversum egresso scribe. meis listis conscribementa II tum maximum da. dum damentum nexto listis decapitamentum fac sic lista sic hoc tum nextum recidementum cis vannementa listis da. dictum sic deinde cis tum b…

It's funny, because original version of this library was written in year 2000, so literally more than 20 years ago (my example of "old") :)

https://metacpan.org/dist/Lingua-Romana-Perligata/changes

Re: Python: Please stop screwing over Linux distros

#304
post #176
post #134

Earlier quoted context omitted.

> Perl is a godsend... take a code from 20 years ago, run it on a modern system, and everything works. That's more or less like "take a VB6 binary from 20 years ago, run it on some modern Windows, and everything works" - that's just because the ecosystem is effectively dead, so supporting it on new releases just means carrying over some stuff that worked 20 years ago.

What's the sin in supporting stuff that works?

This is the sad reality of modern development... new project? Why take some stable tech, when you can take a 2month old framework and an alpha version of a library, and do two rewrites, before the project fails due to breaking changes and abandoned software. It seems as if people actively avoid anything stable.

Re: Python: Please stop screwing over Linux distros

#305

Earlier quoted context omitted.

Yes, exactly this. Only I view it from the other way round: to try to do development with distro-supplied language packages is a category error. Distro-supplied interpreters and their associated libraries are there for the applications supplied and supported by the distribution . Unless you are developing something to be part of the distro, they are not for you . Do not let the distro get between you and your librari…

>Unless you are developing something to be part of the distro, they are not for you. . . . forgetting the original purpose and mindset behind Linux in the first place. From a 1990's point of view; it was always intended to be a hobbyist OS; and in most cases, one had to compile all the binaries and kernel one's self. There was no such thing, really, as a "user" or "admin" - everyone was considered, and expected to be…

Yes, and distributions arose to solve the problem that plagued early Linux: how to have a set of applications and libraries with consistent and mutually compatible versions of everything. If you're compiling everything yourself, building it so it all works once is an achievement. Keeping on top of as many moving targets as there are binaries in the system so that everything keeps working over time is not practical once the number of moving parts gets high enough.

Distros solve a real problem, but the trade-off is that some parts of the system must exist to serve itself.

Re: Python: Please stop screwing over Linux distros

#306
post #7

I am not one to install python packages using my distro's package manager, but I totally agree with the sentiment that we need a more standard build/dependency management system in python. I like poetry, and I think most people are heading that way, but it doesn't seem to play super nice with pyenv (which is a critical tool) a lot of the time, and I think that a first party endorsement of the "one true build system"…

Golang is a great model to follow. I think the fundamental thing that python (and ruby, when I still used it) has taught me is to run a mile if a language is without a robust dependency management system. The pain is just not worth it, even for a nice language with an otherwise robust ecosystem.

Go is terrible for distributions to package due to the poor library versioning. Also, static linking makes security updates really expensive to build at scale.

Re: Python: Please stop screwing over Linux distros

#307
post #88

Earlier quoted context omitted.

This is the real legacy problem: Python comes from a world, where only one version of one packaged seemed the right way to do. I do not have a good idea, but other ecosystems evolved much more sane in the realm of packaging. While not ideal, Go has done a fairly good job - and the "module" operations are instant - which they should be.

Go is terrible for distributions to package due to the poor versioning of libraries.

Despite the downvotes, the argument stands: linux distributions are having a hard time handle the amount of tiny libraries and the conflicts in versioning and many maintainers voiced their concerns in the past years.

The HN bubble can be amazing sometimes.

Re: Python: Please stop screwing over Linux distros

#308
post #272

Earlier quoted context omitted.

PyQt only contains the bindings. You share the same Qt environment across your system (hence qmake needs to be in your path). The python package itself is not that big (~10 MB).

The comment on top of this chain is about letting every package specify its own versioned dependencies. So how would that global version work out when python needs 5.1 and some other software specifies 5.2?

Qt minor releases are backwards binary and source compatible, but not forward. Therefore this would not be an issue.

Re: Python: Please stop screwing over Linux distros

#309

Earlier quoted context omitted.

I really doubt that the python libraries packaged by Debian are any more secure or stable than the latest release of those libraries. At best they just limit to breaking updates to once every few years when they update them. It’s essentially like version locking packages except some random Debian maintainer decides when it’s time to update.

The python libraries packaged by Debian are provably more secure or stable: they receive security backports while also not receiving feature updates. The combination of this 2 aspects is what provides better stability and better security. > It’s essentially like version locking packages except some random Debian maintainer decides when it’s time to update. Not at all.

That is not "provably more secure or stable". I think it's pretty safe to assume that maintainers backporting security fixes is more secure than just not updating at all, but even that isn't proven. It being more secure than updating is much more questionable, and is probably going to vary greatly between packages.

Re: Python: Please stop screwing over Linux distros

#310
post #237

Earlier quoted context omitted.

Not if they pull in all of their dependencies, PyQt would have a complete copy of all Qt binaries and a complete chrome install because of course Qt includes a browser based html viewer. Python packages are gigabytes.

Fortunately there are a thousand gigabytes in a terabyte and nobody is using a system with single or double digit gigs of storage anymore. Unless you are trying to save a buck it seems 1TB is the standard today. My primary desktop has 4.

> Unless you are trying to save a buck it seems 1TB is the standard today.

I suppose part of the problem is that while getting a 1 TB SSD instead of a 512 GB or even 256 GB one may not be overly expensive (for a middle-class person in a wealthy country anyway), due to the way OEM laptop product lines are often stratified, you may need to either buy your 1 TB SSD separately or get an altogether higher-specced model than your perhaps otherwise would. The latter especially isn't cheap.

There might be some customization options but sometimes little customization is available. That's probably one of the ways people end up with relatively small-capacity SSDs.

It's kind of similar as with RAM: a higher capacity isn't that much more expensive in theory, but in practice it may be.

This is irrelevant for custom-build desktops but lots of people are running only laptops nowadays. I'd like to see better customizability for the builds, as well as upgradability and replaceability, but the options are often limited.

Post reply on HN