3 ms·
This thread is a classic example of something that happens over and over. Someone says something is hard to use. 1/3 of the responses agree. 1/3 of the respo
by gfunk911 16y ago
This thread is a classic example of something that happens over and over.
Someone says something is hard to use.
1/3 of the responses agree.
1/3 of the responses disagree, say it's simple.
1/3 of the responses say it's simple, all you have to do is use additional software package Y to manage X and it works great.
This is usually a sign that there is some merit to the original assertion.
- dschobel 16y agoWe're talking about technology, not politics so consensus be damned. There is a fact of the matter independent of perception and lack of consensus in and of itself is not a valid attack on a position. In this case maybe we can listen to those who claim the python situation isn't that bad and have provided specific technical solutions for evaluation.
- gfunk911 16y agoIf the question is "Do a significant number of users run into problems with a piece of software," then the consensus is absolutely relevant.
- dschobel 16y agoThe question isn't whether there is a problem but whether there is a solution. The virtualenv/pip people seem to think so.
- masklinn 16y ago> The virtualenv/pip people seem to think so. No. Unless those people are morons, but the guys who actually code them know they're tools for python developers, and maybe for sysadmins of python solutions. Pip and virtualenv for software using Python as a config file format? not a good idea.
- zedshaw 16y agoYes, pip/virtualenv works for installing things like Django. It totally fails for something like m2sh which has to live in the system PATH so that you can run it from wherever you have your configs. But you know, I wonder if the various distros could sort of invert this and they start using pip/virtualenv instead of everyone else working around them?
- jacobolus 16y agoThe distros should be shipping two versions of python (if they need), walling their required old version off somewhere but actively and explicitly including a newer one higher up in the $PATH so that people don’t have to mess with the “system”. The problem is the combination of “system”, “third-party tools”, and “users” trying to use the same python with completely different upgrade timelines. If all of these distros included by default a recent-ish version, and their package managers made updating that one a snap, then third-party tools could stop trying to use system python for anything at all, and users could forget that the “system” python existed. Unfortunately, since the problematic old python versions are on existing old distro versions, it’s not clear that there’s any easy way to fix this problem.