perhaps system python can be used by only the system user, and any human users must install their own python.
Python: Please stop screwing over Linux distros
281–290 of 384 posts
Re: Python: Please stop screwing over Linux distros
#282Earlier quoted context omitted.
> Distros assume responsibility for fixing major bugs and security vulnerabilities in the packages they ship. I think they should just ship Python programs, not libraries. They could check what libraries given Python program uses are safe in the version that it uses them. And just don't care if each of Python programs has a separate copy of the libraries or if particular version of particular library is shared betwee…
So, patch two dozen copies of slightly different versions of the same library included in all those programs, instead of patching just one?
You should patch two dozen python programs as a whole that use vulnerable version of libraries. Treat Python programs as if each of them was a single executable file and you only have information which versions of libraries it has inside it. And if any of those is known to be vulnerable treat whole program as a security threat.
Re: Python: Please stop screwing over Linux distros
#283Earlier 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.
Buying a 1TB external SSD would more than double the cost of a raspberry pi 4 that and my ancient beagle board does fine running from 32 GB.
> My primary desktop has 4.
Those are rookie numbers for a primary system. Of course my Office system next to it is a lot lower specked with the test system next to it even lower.
Re: Python: Please stop screwing over Linux distros
#284Earlier quoted context omitted.
There are some differences indeed: - python is more active than most alternatives, you have new packages created every day. - python is massively used outside of the web, unlike JS, ruby or PHP, that are 99% web. You get Python in SIG softwares, data analytics, automation, pen testing, sysadmin, biology, etc. It's a huge graph. - python is used by the distro themselves to code features of the OS. E.G: you remove Pyth…
That's a good analysis, thanks. But I don't think any of it justifies the ire towards Python, its community, or its devs that was expressed in the blog post. I also do want to point out that there are quite a lot of general-purpose CLI tools written in Perl, Ruby, and Node.
The distros devs live in their own world, they don't have to work on a fast api service connected to a sap db that must run on windows with no admin rights for dev but must be deployed on centos 7.
Re: Python: Please stop screwing over Linux distros
#285Earlier quoted context omitted.
> That's because there is one obvious distribution of Python to use Lol, no. There is one in the Windows appstore too, which has issues with privileges. And I'm almost sure now MS ships it in some other tool too.
I wonder what percentage of the six people who use Windows app store have found that situation confusing.
Fun fact, if you type "python" in a cmd in windows 10 but no command is found, it opens the windows store and prompt you to install python from there.
Re: Python: Please stop screwing over Linux distros
#286Earlier quoted context omitted.
I wonder what percentage of the six people who use Windows app store have found that situation confusing.
Fun fact, if you type "python" in a cmd in windows 10 but no command is found, it opens the windows store and prompt you to install python from there.
I don't doubt the factuality of that statement but the fun part is definitely questionable.
Re: Python: Please stop screwing over Linux distros
#287The OP mixes together different tools used for different causes.
* setuptools/pip/poetry is package managers
* egg/wheel/? are package formats
* venv/conda are environment to isolate from the OS
Over 12 years with Python the only serious change I saw was setuptools (was it named like that?) => pip in 2011. The only serious issue I saw was when I installed with several managers (OS, setup.py, pip) and/or as root/user. That got solved in 15-30 minutes after checking the imported package __path__, and cleaning things up.
Teaching people at courses, I saw people who struggled the most never checked anything: doesn't work? They'd try installing harder, or just re-ran things. But they never checked where the packages were installed, and where from they were imported.
Otherwise, I came to following simple rules:
1) python & ipython are installed via an OS package
2) packages that have to be executed like jupyter may be installed as root, or user; just never install both.
3) all other packages are installed as user. Computers are personal, and I almost never execute things as root, nor have other users.
Maybe being able to examine sources of errors was why I didn't feel it was so hard? I'm not a sysadmin, nor a hardcore programmer. It's just I got used to check paths and read error messages attentively.
This does not mean it's easy, I wish things were simpler, there were less ways to do things, but the OP exaggerates things as if there's a thousand of tools.
Re: Python: Please stop screwing over Linux distros
#288The OP mixes together different tools used for different causes. * setuptools/pip/poetry is package managers * egg/wheel/? are package formats * venv/conda are environment to isolate from the OS another degree of complexity is added by the OS: their package managers and ability to install as root vs under user. But in any layer, there's not much to get confused. Over 12 years with Python the only serious change I saw…
> The OP mixes together different tools used for different causes.
The fact that it is possible to get all of these confused is in itself a problem I'd say :(
Re: Python: Please stop screwing over Linux distros
#289Earlier quoted context omitted.
> Distros assume responsibility for fixing major bugs and security vulnerabilities in the packages they ship. I think they should just ship Python programs, not libraries. They could check what libraries given Python program uses are safe in the version that it uses them. And just don't care if each of Python programs has a separate copy of the libraries or if particular version of particular library is shared betwee…
So, patch two dozen copies of slightly different versions of the same library included in all those programs, instead of patching just one?
Why not? Its cheap resource wise whereas dependency hell is potentially debilitating. For some reason many proponents of the package management status quo are blind to this. Having multiple versions of a dependency is only bad in so far as its "messy". It isn't objectively bad. But having a system that breaks applications because two or more cant agree on a package version is objectively bad. Its arguing aesthetics versus getting the job done. A poor position.
Windows, for all its faults, doesn't have this problem. It will happily accommodate multiple versions of say, .Net as needed.
Re: Python: Please stop screwing over Linux distros
#290Earlier quoted context omitted.
So you're suggesting always using virtualenv? I used to just use pip to install to the system. Months/years later I would try to untangle the mess of packages I was just playing with, what the OS wanted/needed, I got those conflicting dependencies you mention, etc. I usually ended up reinstalling the OS. At the time I may not have been as knowledgeable about where the OS package manager keeps packages vs pip--but the…
I was slow to get to grips with venv. It sounds like you are on the same path. This note tries to be constructive advice - * Some distro software uses python. Let the package manager take care of dependencies for that. * For everything else, use an dedicated virtualenv for each codebase you are working with. > I used to just use pip to install to the system Never do this, for the reasons you cite. > I've dabbled with…
Thanks for taking the time to share!
That's sounds like the general approach I take for "projects" even toy projects. My day jobs have never fit the virtualenv use-case. So at home I often have to look up how to use it. It's so rare that when I make an alias I even forget those.
Most new things are one-off scripts; move or rename some files, extract data from something, or pull from a resource. Something that requires libraries or is too big for a shell script. For example, the last one I see in my bin is a web scraper for appointments. It pulls a website, fills out a form, and gets the result a few times--about 70 lines. What's annoying is sourcing some environment just to run this one tool.
Most people have a directory of scripts (a mix of shell, Perl, or Python) they use if they spend a lot of time at a commandline. It's quite a pain to source the environment just to run a quick script. That's generally the libraries I install into user. I don't care much about the version and troubleshoot things as they come up.