181–190 of 384 posts
Actually, this is not sane.
If you have any Python dependencies, you should always develop and deploy your code using virtualenv, never by installing packages into the system Python!
Earlier quoted context omitted.
Apt install python-pip3 You'll get pip3 from Python 3.6. apt install python3.8 You'll get system-level python3. Use pip3 in 3.6 to install the latest pip3 that requires Python 3.8, and drops that package in the dist-packages folder, which is shared between system Python runtime versions. Behold as further attempts to do something sane with APT blow up, because now you have 3.8 packages on 3.6's runtime path. I've los…
"Thou shalt not mess with the system Python"
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. 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 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.
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.
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.
Ok but Go compiles statically, while you can do the same with pyinstaller, I don't think that's really comparable as we're talking about deployment right there.
Sketch for python: Create a ~/.cache/python/packages directory. Manage all dependencies there. Make the python interpreter "package aware" so that required dependencies are read off a file from the current project (e.g. "py.mod") and adjust "system path" accordingly and transparently. Or something along those lines.
No extra tool, a single location, an easy to explain workflow (add a py.mod file, add deps there with versions, etc).
I'm just thinking out loud, but it does not need to be hard.
Earlier quoted context omitted.
I'm using Anaconda, it's so far hands down the best way to manage python and its packages. It just works.
hands down the best way to manage python and its packages. Agreed, especially on Windows. It just works. This is pushing it. It's not hard to break conda or put yourself in situation where the updater/dependency checker gets stuck and doesn't know what to do, especially once you start adding conda-forge packages. But it does do a better job than anything else I've tried (although poetry + pyenv on Linux is getting mu…
Am I the only one that is not having issues with python and distributions in general? I get all my dependencies from Debian and they all work, when I need something that is not yet packaged, I use pip. What are people doing to get all this issues? I don't understand...
Trying to get the script to run on other OS's than just Debian (or Linux).
It seems a bit weird to criticise lots of people for trying to solve the dependency problem. I know lots of people hold up npm as the standard. Npm came out around 10 years ago, Node around 12. Both of which had the benefit of hindsight at how the problem had developed for other languages. Python came out 30 years ago and pip came out 20 years later. Of course there is a lot of stuff left behind. What do people sugge…
IMO, the Java or APT packaging ecosystems solve the issue in a far superior way.
Earlier quoted context omitted.
Ok but Go compiles statically, while you can do the same with pyinstaller, I don't think that's really comparable as we're talking about deployment right there.
Static binaries are a different story. Go has dependencies as any other modern language and they had a bad story in the past and have a better story today. Sketch for python: Create a ~/.cache/python/packages directory. Manage all dependencies there. Make the python interpreter "package aware" so that required dependencies are read off a file from the current project (e.g. "py.mod") and adjust "system path" according…
Are you saying "put the different version of every dependency you need in there if you have to"?
Because I don't think package managers are ready for that, they usually like to have one version installed per package.
The success of Python and Go shows that people don't care as much about what distributions maintainers feel is "quality packages". The scale and quantity of software being developed is just too much for traditional Linux distributions approaches. I personally rely on Debian to know that most of the packages I use are reasonably secure. But often I need to sacrifice flexibility and bleeding-edgedness. And it couldn't…
Earlier quoted context omitted.
> Get rid of the requirement that there is only one stable (minor) version of a package in the distribution at one time. I think this requirement made sense when disk space was scarce. I think this requirement makes sense if you trust that your distro is always better at choosing the 'best' version of a dependency that some software should use than the software author. Nowadays, I think neither is generally true. Dis…
> Disk is plentiful, What makes you think so? SSDs aren't exactly stellar in the cost-per-TB department, as will be the case with each new higher-performance storage technology. Plenty of people cannot afford the prices of new Western tech either, what about them?