21–30 of 93 posts
I think they are misreading the situation. The devil is in the details. It seems `getHeaders` v. `headers` is non-security, non-performance related issue. Why people should spend time fixing these?
Otherwise, I'd say that's a very brave comment you are making.
Wait, does urlib not use semvar? Don't remove APIs on minor releases people. A major release doesn't have to be a problem or a major redesign, you can do major release 400 for all I care, just don't break things on minor releases. Lots of things not using semvar that I always just assumed did.
As an example, I always knew urllib3 as one of the foundational packages that Requests uses. And I was curious, what versions of urllib3 does Requests pull in?
Well, according to https://github.com/psf/requests/blob/main/setup.cfg, it's this:
urllib3>=1.21.1,So, it seems to me that even the Requests folks assumed urllib3 was using semver.
>We ended up adding the APIs back and creating a hurried release to fix the issue. So it was entirely possible to keep the software working with these. Why change/remove them in the first place? Is the benefit of of the new abstraction greater than the downside of requiring everyone using the software to re-write theirs?
OS software maintainers don't like maintaining legacy ugly APIs forever and want to refactor/remove legacy code to keep themselves sane and the project maintainable.
Of course, the reality is hardly ever as bad as that, but I'd say having to deal with trivial API changes is a reasonable basis for a user to dislike a given project or try to avoid using it. It's up to the maintainers how friendly they want to be toward existing user code, and whether they pursue mitigating options like bundling migrations into less-common bigger updates.
Fixing deprecations is unfortunately the lowest prio of any kind of work for majority of the projects. Part of the problem is probably lack of pressure to do so it if the timeline is unclear. What if this is actually never removed? Why going through the pain? IMO telling "we deprecate now and let's see when we remove it" is counterproductive. A better way: deprecate now and tell "in 12 (or 24?) months this WILL be re…
... and the right answer to that is to make it entirely their problem.
> Part of the problem is probably lack of pressure to do so it if the timeline is unclear. What if this is actually never removed?
In this case, the warnings said exactly what release would remove the API. Didn't help.
> Why going through the pain?
Because you're not a feckless irresponsible idiot? I don't think it's an accident that the projects they said didn't react were an overcomplicated and ill-designed management layer for an overcomplicated and ill-designed container system, a move-fast-and-break-things techbro company, and what looks to be a consolation project for the not-too-bright.
You probably get an extra measure of that if you're operating in the Python ecosystem, which is culturally all about half-assed, 80-percent-right-we-hope approaches.
The right answer is to remove it when you say you're going to remove it, and let them pick up the pieces.
It also helps if you design your API right to begin with, of course. But this is Python we're talking about again.
Deprecations via warnings don't reliably work anywhere, in general. If you are a good developer, you'll have extensive unit test coverage and CI. You never see the unit test output (unless they fail) - so warnings go unnoticed. If you are a bad developer, you have no idea what you are doing and you ignore all warnings unless program crashes.
Fixing deprecations is unfortunately the lowest prio of any kind of work for majority of the projects. Part of the problem is probably lack of pressure to do so it if the timeline is unclear. What if this is actually never removed? Why going through the pain? IMO telling "we deprecate now and let's see when we remove it" is counterproductive. A better way: deprecate now and tell "in 12 (or 24?) months this WILL be re…
The urllib3 package doesn't use SemVer.
>We ended up adding the APIs back and creating a hurried release to fix the issue. So it was entirely possible to keep the software working with these. Why change/remove them in the first place? Is the benefit of of the new abstraction greater than the downside of requiring everyone using the software to re-write theirs?
Earlier quoted context omitted.
Why is it that CI tools don't make warnings visible? Why are they ignored by default in the first place? Seems like that should be a rather high priority.
It isn't that easy. If you have a new warning on upgrade you probably want to work on it "next week", but that means you need to ignore it for a bit. Or you might still want to support a really old version without the new API and so you can't fix it now.
So you create a bug report or an issue or a story or whatever you happen to call it, and you make sure it gets tracked, and you schedule it with the rest of your work. That's not the same thing as "ignoring" it.
Users don't notice a deprecation warning. But they might notice adding a "time.sleep(10)" immediately at the top of the function. And that gives them one last grace period to change out their software before it breaks-breaks.
I think they are misreading the situation. The devil is in the details. It seems `getHeaders` v. `headers` is non-security, non-performance related issue. Why people should spend time fixing these?
If you (either directly or from SerpApi) are supporting the urllib3 folks (through a Tidelift subscription), then yes, that is a valid point. Otherwise, I'd say that's a very brave comment you are making.