Glad he made the sane option, I held off from converting my eBook library to the system because of the previous python2 ignorance.
Calibre has been completely reliable on the multiple e-readers and computers I've used it on.
The only reason this migration is taking place because out of the thousands of people on this forum who complain about his code, several of them decided to help him instead of continuously complain.
I don't understand this hypercritical way of looking at things, especially considering how powerful and useful Calibre is. I plugged in a very old e-reader to my computer and tried a variety of things to put books on it; Calibre was the only thing that worked (including the actual ereader software!) I can't imagine how much work something like this would take to maintain.
If anything, the user experience has been diminished in the move to Python 3, as the maintainer mentions some 3rd party plugins won't work as they need to be ported over.
> there are a bunch of emotional people
> or some nonsense like that
> Easy for especially weakly socialized young people that many programmers are
It's amusing to watch you call others "weakly socialized" when reading the rest of your comment. Social awareness is not exactly exuding from it, what with the judgments and the confident assertions.
I don't think any good alternatives exist, but if they did, I'd probably switch in a heartbeat. The lead developer for Calibre is extremely annoying. RMS is easier to deal with.
As would I. On a higher order of infinity, I'd use the work of a competent saint over a competent asshole.
Let's not make false dichotomies.
If as a dev one ~not know~, assumes that their code base will have issues because its python 2, then the dev has some issues.
As a case study in open source development, I find it fascinating. In large closed source products, these discussions and their relative dissent is held behind closed doors. I wouldn't be surprised if large parts of YouTube remain Python 2 for a long period of time. But the product owners are aware of these tradeoffs and wouldn't allow public discussion on the subject.
Calibre, from what I've heard has had a historically "bad" codebase. I know nothing about it. But is it the truth?
It feels like a vehicle that has been organically modified over the years by a person who only has a welding machine and a cutting torch and a changing taste in what looks good. But hey: it drives.
Of course you have to know the intricate of the machine to make it behave, but isn't that part of it's charms?
I have noted this quote and intend to apply it to every large software stack I work on from now on because damn if it isn't true of all of them.
Not liking how something works doesn't make it wrong or broken.
So what is this "bad codebase" you seem to feel?
This would mean considerable dev time to track bugs in the language and dependencies that have been fixed by others in their Python 3 variants. And that means a dev that could have worked on new features now works to do (silly) maintenance work. This clearly does have an impact in the long run.
I am working with Python myself. Everything I moves to Python 3 was a one-time effort, while the stuff where I had stayed with Python 2 means constant effort of making sure it is still safe and no major bug has been discovered in the deps.
I understand the annoyance people have with this, but there aren't to much rational arguments why to use Python 2 over Python 3. In fact it would be the other way around. Before it was minor differences, but the language evolved in a good way since ca. version 3.5 and some of the solutions are really useful (typing, dealing with encodings and unicode, not having to make sure you are using floats when dividing two numbers etc.)
In practise by far the biggest difference is that print foo becomes print(foo), and that is not a big deal if you ask me
The new names are without a doubt better. In a vacuum. But coming from Python 2 to Python 3 and dealing heavily with encodings because I use Python for massaging machine-generated reports, the fact that they reused the same datatype identifier for bytes in P2 as for unicode in P3 really put me off.
Now that I've made the change (OK, six years ago) I'm much happier with the way Python 3 handles bytes and unicode strings. I think it is a model that all languages could learn from. But it should have been called <string> or stayed <unicode> instead!
So it’s kind of harsh to judge that statement in that light isn’t it?
Everyone at that time knew that Python2 is dead and that everything is in transition to python3. Most new code was written for python3 and not even compatible for python2 anymore. So it really was just one guy deciding to maintain his own fort on his own.
Plus as port itself doesn't affect any user experience, it was not emergency situation. It is just that 'we are working FREELY with our own pace, so it will take time. Actual contribution is really appriciated than complains'
There is another similar program I miss is, leafpad. It is dropped by distros as not yet ported.
This balance — however — can change with time. E.g. if one of your major dependency moves to Python 3? Or gets abandoned.
I didn't say it was easy, my point was that over time more and more dependencies make a shift to Python 3 as well, which means at some point Python 2 stuff becomes harder to maintain. Whether that point happens early or late depends entirely on the project.
Additionally I nowhere said that this must be done by anyone — you are projecting here.
If you've ever developed for linux, you might come down on the side of the server folks. You will find that there's a web of dependencies everywhere that you will have to navigate. And the more higher-functioning what you are doing, the more likely this will become more and more complicated.
If people depend on an app, develop for something like Ubuntu 16.04 or Ubuntu 18.04. It is (more) likely that people will be able to use it without trouble for quite some time. It is very stable and it is not likely updates will affect the folks using your software. They will be able to use the software for years.
strangely, I wonder if arch linux might be the counterpoint to all this. You might just do continuous maintenance all the time instead of one-giant-upheaval-update every few years.
Simply using the "USER <uid/uname>" directory means you run as non-root user with a specified UID. Kubernetes recommends doing that as a baseline security measure. You can also drop caps from a container so even if you are root inside, you can't do a lot of things root can.
I wish there was a way to say:
LAYER foo
RUN unpack_some_large_package
RUN build it
RUN install it
RUN delete stuff
LAYER bar
and the efficient use of docker is unreadable and hard to maintain:
RUN unpack_some_large_package && build it && install it && delete stuff
This is lots harder nowadays over vpn.
I know there's docker squash, but that is a hack on many levels.
Then there's the firewall thing
and last, I'd like to have my own private repository - where docker wont' and can't pull from other machines.
https://docs.docker.com/develop/develop-images/multistage-bu...
Evidently, one of the people mentioned in the calibre blogpost helping the python3 migration is an Arch Linux contributor :)
I've been using his Arch repo shipping Calibre with Python 3 for I think over a year. My system is updating to Calibre 5 from the main repos as we speak, so I guess I'll remove the custom repo now.
Now I'm only waiting for the Kodi 19 release before Python 2 will be gone from my system forever...
Not to diminish the work of Eli, but several Arch package maintainers end up bugfixing upstream projects to keep sources unpatched. Personally done upstream contributions to several upstreams I maintain in the distribution :)
(I'm not an Arch TU or dev, but I also contribute upstream fixes for AUR packages I maintain)
It's like...how many times do security researchers have to exploit your code (and your many "fixes") before you change your program's mounting architecture?
I read this bug report when I want to feel something.
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
"Don't feed egregious comments by replying; flag them instead."
I remember installing calibre once, because I needed to open an .epub file I had. Upon opening it, it started to "classify" stuff and build a sort of catalog, to which I kill -9'd it immediately and uninstalled it for good measure. But mounting filesystems is way, way worse than anything I imagined it was about to do!
You really can't blame a program to do what it says to do.
It can manage eBook readers' libraries either natively or via plugins. It can work with my Kobo eReader for example. I use Calibre to convert standard epubs to kepub (kobo enhanced epub) and push to device and extract highlights from books mainly. It's also a very nice ebook library so I can search and push/read/modify what I want.
It's more justified to call it an IDE for Ebooks.
Maybe time to let it go?
Unless there are more recent examples to point to. Or the problem still is not fixed.
That's more ignorance that arrogance. He fixed what he understood, and discussed what he did not understood till he found a satisfying solution.
Personally I wouldn't trust a dev who fixes stuff blindly which they don't understand. Though, in case of security this of course can have also bad outcomes, as illustrated in this case in the process. But that makes it even more important for everyone to follow through and communicate clearly. Which did happen here at the end.