@emsenn @enkiv2 @feoh
Theoretically, the code I'm writing ought to be portable (and @gcupc caught & reported some cases in previous versions where it wasn't). I don't use python 3 as my default python distribution because most python libraries & apps I use still haven't been ported or made compatible (although that might have changed in the 3-4 years since I last had trouble with that).
@gcupc @enkiv2 @emsenn @feoh
I try to stay away from libraries in general but especially major libraries. From my experience installing lunar again, it looks like python3 is safe to move to if I don't mind reinstalling all third party libraries. I'm not doing that on my main machine, but it's about time to wipe it anyway...
@enkiv2 @gcupc this is why I'd recommend every Python developer use virtualenv or one of the higher-level wrappers around it, such as https://virtualenvwrapper.readthedocs.io/ or https://pipenv.readthedocs.io/ or https://direnv.net/
of those, direnv is more general than just Python and I love it; I blogged about another use for it recently in https://jamey.thesharps.us/2019/05/29/per-project-postgres/
@enkiv2 I don't understand: either a new release of some program is incompatible with the versions of some of the libraries you have installed, in which case of course you have to install new versions of those dependencies; or it's compatible with everything, in which case virtualenv certainly doesn't require you to change anything.
Or are you referring to major/minor releases of Python itself? The site-packages directory is always in a path named after the Python patch release, so if you change Python version at all you have to reinstall everything even if you're using distro packages, although your distro likely takes care of that behind the scenes for you.
But you shouldn't have to redownload anything if you're using the same version of a library, as long as pip is configured to cache downloads, which I think it is by default these days.
I'm talking about site-packages. My local site-packages consists of the hundreds of python 2.7 libraries that were installed as dependencies for applications. My site-packages for 3.x is basically empty because it's only the dependencies for the handful of applications (like youtube-dl) that have ported to 3.x instead of maintaining 3 compat. I have both installed, but `which python` gives a symlink to 2.7
@enkiv2 So... are you saying that because you've installed things for Python 2 in the past, that makes it better than Python 3? I'm trying to understand, but I'm utterly baffled by whatever you're trying to say here.
Anyway, you know Python 2 has about six more months before it ceases getting any bug fixes, right? It'll be entirely unsupported upstream as of January 1st. (https://www.python.org/dev/peps/pep-0373/)
I'm saying that I develop on python2 because that's what python points to in my path. I avoid python2 features that are obviously not forward-compatible, but I don't go out of my way to test on python3 because that would involve going out of my way. If distros start using python3 as the default python, I will be testing against python3 & all my libraries will be installed in python3's site directory.
Python is my 'I don't want to do this in shell but also don't want to think about the appropriate tool to use' language. When I'm using it, I'm expecting the number of people who ever actually run the code other than me to be no more than ten, & the primary driver for using python over something else is the fact that an enormous number of dependencies are already installed.
@enkiv2 Well, okay, I think you're in for a world of hurt which you could avoid without much trouble, but that's certainly a stance you can take and I'll leave you to it.
@enkiv2 @jamey You will probably not be interested in the patches in my personal fork of fern, but if that's not the case, I can package them as pull-requests for you. They add support for using pipenv to manage dependencies, use of black for code formatting (removes most Python 3 incompatibilities), and optional support for XDG config paths.
I've added one small dependency (xdg), but it's inside a try/catch block that will simply do what you already do if it isn't installed. I'll see if I can format my changes into minimal separate pull requests.
Python does indeed have a lot of good libraries. That's part of why I use it. Not only does it have a big ecosystem of useful libraries, but a whole lot of stuff ships with every python install.
However, I find that a lot of libraries are sort of pointless. Somebody who is worse than I am at programming has solved something that is not quite my problem in a way that I wouldn't like to solve it.
So, generally speaking, I'll use a library if it does something I don't know how to do & don't want to be arsed to learn how to do, or if it does what I want to do in a better way than I would to it.
I won't use a library for the sake of using a library, though, because I find that often it's easier to reimplement the parts of the library I need myself than work around the awkward way the implementer exposed their code.
@feoh @enkiv2 @gcupc @emsenn
Well, my attitude is that I'm just being sensible, but the end result is that I use libraries a lot less often than other people do (except for a couple guys at work who are hyper-conservative about dependencies & don't install anything they haven't read and understood the source for).
ｃｙｂｒｅｓｐａｃｅ: the social hub of the information superhighway
jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal