Revert "Merge pull request #155048 from mweinelt/python2-must-die"#157959
Revert "Merge pull request #155048 from mweinelt/python2-must-die"#157959Profpatsch wants to merge 1 commit intoNixOS:masterfrom
Conversation
|
For reference, I use lilyterm as my main terminal emulator application, and it didn’t just suddenly stop working because python2 hit an arbitrary milestone. |
|
|
||
| #### BINDINGS | ||
|
|
||
| libglademm = callPackage ./bindings/libglademm { }; |
There was a problem hiding this comment.
This file appears to be missing.
There was a problem hiding this comment.
This is curious, I reverted the merge commit, maybe something went wrong.
There was a problem hiding this comment.
What happened to deprecation periods?
There was a problem hiding this comment.
What deprecation periods do you mean? I never heard of any.
There was a problem hiding this comment.
It's possible in nixpkgs to have lib.warn as part of normal evaluations. Ofborg treats these as errors. We could potentially shove the warning into the alias scope, but I haven't seen anyone do that.
|
Also, I believe @samueldr was working on GTK 3-based lilyterm. |
|
@AndersonTorres I am not okay with removing software I maintain without a deprecation period. |
Python 2 is EOL. Gtk 2 is EOL. This is not an "arbitrary milestone". It means that people stop investing their free time in keeping besaid software secure and running. Over time, all packages need to be fixed, updated or removed. This is what other distros do as well. A lot of these packages are abandoned, unmaintained – either upstream, in nixpkgs, or both – or have a newer successor. Of course, I prefer it when packages can be fixed and don't need to be removed. I use some of these packages too. In #157959, I tried to ping all maintainers of affected packages. I am sorry if you somehow weren't noticed in there. I you can bring a few packages back without the old dependencies (like in #157868 for example), that would be awesome. Otherwise, we are in the fortunate situation that we can simply pin old |
|
We should stop treating the harmful situation that we tolerate software systems needing constant changes as desirable. |
|
This throws a very bad light on Python, GTK and also the nix maintainers of said environments. I don’t trust them anymore to support software I use for more than a few years. I will adjust my views accordingly. For the record, lilyterm does not depend on Python, it depends on vte, which had an optional dependency on Python, so this should have been unnecessary. |
Gtk 2 has been in LTS mode for over a decade. Python 2 has prolonged their support frame for several years compared to the planned EOL. For reference, the commercial Java ecosystem wants to get paid after a few years for support. Just because some software is not supported anymore does not make it instantly go away. The old nixpkgs versions are still there, and they won't change. But please understand that people do not want to invest their free time in keeping some obscure software with a handful of users from a past era alive.
Maybe, yes. Again, if you can bring back the package without those dependencies that would be awesome. |
This arbitrary milestone is know as "Python developers are tired of maintaining Python 2 for more than 10 years".
Looks an interesting and useful policy to me. However, I never heard of a deprecation period on Nixpkgs before.
This is good news! If VTE is not hard dependent on Py2, it is possible to resurrect it! I will work on it. However, it should be noted that lilyterm has no new releases for a long time. |
|
I have tried to build lilyterm-git. Here is it: It looks like a hard dependency on GTK2. |
|
Just saying, since I was pinged, I won't be using the Nixpkgs-provided lilyterm since anyway I was heavily patching it already to remove features. But the tip-most git revision did work with GTK3, albeit it fails at runtime due to other issues. I removed some misfeatures (to me) causing issues. You probably don't want to use my fork, but just in case ¯\_(ツ)_/¯ |
|
And I have to agree that removing things hapazardly like that is not a good look. No warning, no grace period (even just one full release cycle). How can I rely on Nixpkgs if things just vanish? If ~6 months ago a warning was explicitly placed, I would have had time to look and fix what I was using. Instead, I had to scramble in two evenings to fixup what is might be the most important piece of software in my software stack. |
|
I will open an issue in Discourse and in matrix about this. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
Python2 was originally announced to be EOL in 2008, and was meant to be EOL in 2016, then extended to 2020. 14 years is a more than generous timelines for ecosystems to adjust and write python2+3 compatible code. I think it's fairly safe to say that software still dependent on python2 in 2022 has been abandoned. |
|
Isn't nixpkgs unstable the place where we should be able to deprecate/remove things? People who prefer to have some grace period can always stick to the stable channels, and read release notes before upgrading to a new release. |
Announcements prior to removal should be made, in a way that gives unstable users time to act. The lack of procedure for correctly handling deprecation is the root cause of the issue. This is not like moving an attribute somewhere else, this is removing a still working package, which users may depend on. It isn't fair to say that in unstable everything goes. Or else we might as well randomize attribute names every few weeks to keep users on their toes. |
Without a warning, the maintainer of the package was unable to know they had to look at the packaging of their packages for reliance on python2. If there had been a warning/grace period for a full release, maintainers could have taken a look, and in this particular instance, fix the packaging. Dropping python2 and python2 actually dependent software, I don't have an issue with. What I have an issue with is the method used. |
I have tried to compile lilyterm without python2 dependency. Nonetheless, It is not working (because GTK2 dependency).
As far as I remember it does not apply because, well, there is a policy to make them have the same name.
Technically the maintainers were called; however by any reason Profpatsch was not called or did not notice. Indeed I removed evilvte by myself, because it was old and unmaintained and with security breaches. |
|
A proper deprecation scheme would warn users too. I misspoke when I said maintainers. We know that in Nixpkgs, a lot of packages are co-maintained by non-maintainer users. With a warning period that is done through the evaluation, users like me, and I suppose @Profpatsch, would have had a heads-up to look at the issue.
The “still working” here means that before the removal, the existing package was working just fine. Removing a package that is obviously broken already is (imo) different than removing one that is currently still working. |
|
It would be nice to have a deprecation mechanism which is compatible with ofborg and hydra. Perhaps we could have something that is "the opposite" of how aliases work today, in which users have to explicitly opt out of. And for nixpkgs machinery we can just do something like Then again, the average user will probably do something like, "Why am I getting a python is deprecation error, when I'm not using it?" |
That's thinking at the trunk, while we're considering leaf packages here. I agree that if the deprecation starts at a level low enough that is un-actionable, it wouldn't be useful. In this particular scenario, the leaf packages that still build would have to be mentioned in the notice, somehow. For packages that currently are broken the value would be much much less. The target of removal was This way "base" users would have a message explaining which package is at fault. While it would be generally unactionable for "base" users, they would be given some time to look for alternatives. More involved users would have a warning (ideally for a full release cycle) about the impending change, and some of them, hopefully, would be able to schedule some time to look at the issue. |
I don't think this could be done generically. From the nix perspective, it's just evaluating thunks. We would need something like The other thing is that we would need some way to differentiate what should be an origin point. Building a nixos toplevel configuration is just a derivation, but it's not really meaningful to have "nixos-configuration-.... depends on python2". However, I could also be complete wrong. cc @edolstra |
I get the Maybe a message like "python 2 is deprecated" gets hit by an average user, and it goes reported to a superior instance, like the local sysadmin that will investigate this. About this, it will be useful some sort of backtrace of this warning - IIRC |
9 participants
No. You can’t just delete software people depend on as their daily
driver based on a skewed idea of deprecation.
This reverts commit a97ae54, reversing
changes made to 37d3f75.
Motivation for this change
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes