6 ms·
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.
by cjfd 5y ago
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 a system can be kept up-to-date using just one software tool (a package manager). You are not going to convince me in a million years that this is a bad idea.
Now, for things that are needed in development you sometimes need different versions, in particular if you happen to have an OS that ships very old versions. For that purpose there should be some sort of tool and not a gazillion tools that are all incompatible and behave in slightly (or not so slightly) different ways. 'python -m venv' is different from 'virtualenv'? WTF?
Also, if your distribution is up-to-date (e.g., archlinux) and you are pinning to older version there is also a problem. As the article puts it 'pin their dependencies to 10 versions and 6 vulnerabilities ago'. And if you actually want to maintain your software in the future you, at some point, have to go to the new version anyway.
- BiteCode_dev 5y agoSure, so my lib works on mac, windows, centos and debian. Tell me how I'm supposed to define my lib python deps ? How am I suppose to package the lib ? Distribute it ? Deal with os versions differences? Allow isolation for my user projects ?
- 1337shadow 5y agoI'm sorry, doesn't pip already works there? Otherwise, there's pyinstaller which is great but it requires an entrypoint so it won't do with a pure lib that doesn't expose any script at all.
- BiteCode_dev 5y agoYes that's the point. We won't use distro packages because only regular python packages allow this. Edit : arf, sorry, I answered the wrong comment, I actually agree with my parent.
- 1337shadow 5y agoAll right, sorry I didn't get it (I'm non native)
- katbyte 5y agoI have apt/brew - I don’t want to install yet another package manager. Anytime I see just use pip I just walk away and find something else.
- ajsnigrutin 5y ago> 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 with their older versions... Even Python 2.x -> 3.x was a pain in the ass too, and even within minor versions, you sometimes get breaking changes.
- toyg 5y ago> 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.
- znpy 5y agoWhat's the sin in supporting stuff that works?
- ajsnigrutin 5y agoThis 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.
- popcube 5y agothey still publish new main version of perl every year, and still support code from perl4.
- jacquesm 5y agoSo, Perl is the new Latin?
- simonh 5y ago>Serving the needs of python developers vs. sysadmins is a false dichotomy. Python developers develop on a system that they need to admin. I couldn't disagree more. Even if the same person is admining a system they develop on, they almost certainly aren't going to admin the systems their users deploy on. The admin role and developer role should be completely separate with different goals and requirements. The system Python should only be used for system scripts. The end. Nowadays ideally it shouldn't even be visible to non-admin user accounts, and users certainly shouldn't be installing packages into the python being used by system scripts, not even using virtual envs. The python your system uses and how it's configured should be decided by the distro. If they want to break it up into weird packages and funky paths, whatever. That's their problem because they and maybe (_maybe_) system admins should be the only people using it. As a developer you should be making your own decision about which version of Python you are using, what modules get installed into it, what venvs you have and how you manage them. This should all be considered with one eye firmly fixed on the target deployment environment and how your Python will be configured there. The right answer, of course, being that you should be packaging the required python along with the application.
- rolandog 5y agoInteresting; how would you isolate the system python from the user in Debian/Ubuntu. Do you have a link where I could learn more about this?
- pas 5y agoDon't put the system python in $PATH. Any command that needs the system python can be launched through a shim/wrapper script that sets the PATH. (Or even better to execute python directly to avoid passing the system python in PATH.)
- rolandog 5y agoWow. It never occurred to me to approach it that way, thanks!
- simonh 5y ago
- agumonkey 5y agoInstead of assigning blame we should interpret the tension as a sign of an important need having no good solution. It's quite challenging to overlay packaging/versionning systems .. but theoretically it's an interesting and general question. Maybe people should model and solve the whole issue (if there's some solution at all; which I hope)