Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python: Please stop screwing over Linux distros

drewdevault.com

Post reply on HN
Print view View original

291–300 of 384 posts

Re: Python: Please stop screwing over Linux distros

#291

Post by Pokepokalypse »

simonh wrote: post #114
BiteCode_dev wrote: post #101

Earlier quoted context omitted.

Yes, explaining to a beginer how to bootstrap python is hell because windows, mac and linux keeps making sure nothing work the same.

Actually, explaining how to get Python working on Windows is far, far easier than on either linux (modulo various distros) or the Mac. That's because there is one obvious distribution of Python to use, the official one, and new versions of it are always consistent and play well together. Yes you can use Anaconda if you want, and people who do that are probably data scientists or something and know what they want to d…

". . . and then he installed cygwin, and decided to manage and run python through the bash environment. . . " (fun fact: the git client's bash shell is actually cygwin. Also; MobaXTerm has cygwin bundled-in as well).

Re: Python: Please stop screwing over Linux distros

#292

Post by thereddaikon »

captainmuon wrote: post #74

Distros, please stop screwing over Python packaging. It is incredible that Debian/Ubuntu pick Python apart and put modules into different packages. They even create a fake venv command that tells you to please install python-venv. What they should just do is offer a bunch of packages like python3.7, python3.8 that install the official python package wholesale into /usr/python or someplace and then symlink one of them…

This behavior is why things like Snaps and Flatpacks have become so popular. Package managers operate under a draconian and outdated mindset that gets in the way more than it helps at this stage.

You can both allow different versions of the same packages to coexist while also managing updates and installation/removal of software. It doesn't have to be this way. Software should be able to ship with its dependencies included and work and not rely on the whims of the OS getting it right.

Re: Python: Please stop screwing over Linux distros

#293

Post by gjulianm »

1337shadow wrote: post #169
gjulianm wrote: post #148

Earlier quoted context omitted.

> Again, if all python package were up to date as in "working together at this point in time" then `pip upgrade` would work. That is impossible, it will never happen. Packages will have different maintenance cycles, some will get deprecated, others abandoned... You can't base your upgrade policy on an impossible situation. > Are you sure you checked in the `*.dist-info` directories? There should be one per package, c…

> That is impossible, it will never happen. Packages will have different maintenance cycles, some will get deprecated, others abandoned... You can't base your upgrade policy on an impossible situation. You realize that if that was "impossible" and "never happening", then absolutely no Python environment would be working ever? > A version conflict should be reported as an installation failure, not allow you to continu…

> 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 this mandatory.

It is mandatory in quite a lot of package managers. APT, for example, will refuse to install packages with conflicting versions or breaking things. It's better to fail early with a clear message than to have a later failure where the cause is unclear.

> Fine, I'll just quickly fix X and open a pull request, like I probably did a hundred times, then eventually if necessary deploy my fork with the fix meanwhile they do their maintenance release.

That's optimistic. What about detecting which package is causing the issue? What if the fix is not quick? What if the package developers are working on compatibility but it's going to take time?

> I don't understand why, but I'm talking about "live at latest release", not "at master".

Problem is similar. You can't live at latest release with software coming from wildly different developers, with wildly different policies on compatibility, versioning, breaking changes, bugs...

> Then the package can just paste the code of the feature in their own, until a new lib does it, I remember having to do that twice in 20 years (except I didn't just "paste" it, but implemented a much smaller version).

Again, pretty optimistic. You won't be able to do that with all packages. For example, right now I have a project that needs to work on Python 3.6 (among other packages). Latest numpy versions dropped support for Python 3.6, so the project needs to restrict numpy versions to maintain compatibility. I can't just take the latest numpy and patch it for Python 3.6.

> Overall, it seems my approach produces versions of my software and software that I depend on that are compatible with all versions because you can always use an earlier version if you really want to deploy on an old python or whatnot, whereas you approach leads to broken packages, tech debt, and blaming the package manager.

You also spend time doing maintenance and debugging on new installations to debug and fix compatibility issues, when those upgrades might not bring any value to the product. In my case, I do that debugging and fixing in a controlled environment, only when I decide to upgrade the packages, and maybe revert/pin the ones that don't have quick fixes. That's the difference. Once a given package is released/packaged for distribution, I want dependencies to be fixed so that every new installation works, and doesn't fail if some developer decided to break things that day.

Re: Python: Please stop screwing over Linux distros

#294

Post by Fatnino »

skykooler wrote: post #260
AnIdiotOnTheNet wrote: post #197

Earlier quoted context omitted.

> SSDs aren't exactly stellar in the cost-per-TB department First of all, 1TB for binaries and libraries may as well be infinite. Secondly, you can get a 1TB SSD for under $100, which is pretty damned inexpensive when you consider it took until 2009 to get HDDs that affordable.

On a desktop, sure. Now that more and more laptops are starting to have soldered-down storage, this argument falls apart.

If you have a laptop with only half a gig soldered in you get what you pay for.

It's almost as bad as complaining about having trouble running modern stuff with your 286

Re: Python: Please stop screwing over Linux distros

#295

Post by toyg »

lvass wrote: post #279
toyg wrote: post #205

Earlier quoted context omitted.

> I've seen a few comments here about how Nix/NixOS fixes the whole python binary/library mess Nix is a bit of a cult. Its theoretical aims are laudable, but in order to get there it forces you to do a lot of work and reason strictly in its own way. Whether all this work is worth the rewards, I think is open for debate.

Chemistry is a bit of a cult. Its theoretical aims are laudable, but in order to get there it forces you to do a lot of work and reason strictly in its own way. Whether all this work is worth the rewards, I think is open for debate.

Except there the laws of nature are either true or false, whereas the ways you can package software are... a bit more than two.

Re: Python: Please stop screwing over Linux distros

#296

Post by Pokepokalypse »

regularfry wrote: post #273
elurg wrote: post #33

Python libraries shipped by distributions are so old that this mechanism is mostly useless for python development. This also applies to many others programming languages which have their own packaging systems. While python packaging is indeed messy the needs of traditional linux distributions are by far the least important. Python packaging needs to better serve the needs of python developers, not those of sysadmins.…

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 a developer.

Re: Python: Please stop screwing over Linux distros

#297

Post by uranusjr »

robertwt7 wrote: post #161
uranusjr wrote: post #146

Earlier quoted context omitted.

Is your unified JavaScript build system using NPM or Yarn? ;)

both works either way with 1 package.json. doesn't that feel good?

I am happy that it actually works identically and interchangeably across tools for you.

Re: Python: Please stop screwing over Linux distros

#298

Post by stonecharioteer »

captainmuon wrote: post #74

Distros, please stop screwing over Python packaging. It is incredible that Debian/Ubuntu pick Python apart and put modules into different packages. They even create a fake venv command that tells you to please install python-venv. What they should just do is offer a bunch of packages like python3.7, python3.8 that install the official python package wholesale into /usr/python or someplace and then symlink one of them…

Checkout the deadsnakes apt repository. It contains all versions of python you could need, and you can install them side by side.

Re: Python: Please stop screwing over Linux distros

#299

Post by ajsnigrutin »

toyg wrote: post #202
ajsnigrutin wrote: post #183

Earlier quoted context omitted.

But it works... it's universally supported on pretty much every os, even by default on most *nix based ones, and new versions and new CPAN modules are still written. In 10 years, with python 4, or even maybe 5, everything will still be broken, and you'll still be claiming perl is dead, and i'll still be using the same stuff I use now, that worked years ago, works now, and will work then.

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.

But that code won't work in five years, because all the distros will remove python3 in favour of python4. (also, the code from 5 years ago written for python 2.x doesn't work now, becauses distros removed python2)

Do you really want to rewrite all your stuff every 5 years?

Re: Python: Please stop screwing over Linux distros

#300

Post by pjz »

bmj wrote: post #259
toyg wrote: 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…

HN has been around for at least 5 years, right? Probably some interesting stats on how many 'Show HN's are live, dead or decomposed. Live: updated in the last year Dead: not updated in the last year, but still available. Decomposed: not findable/available.
Post reply on HN