Re: Why is Classic Selection described as Py3 compatible on the add-ons page?


Luke Davis
 

On Thu, 26 Sep 2019, Joseph Lee wrote:

If we go strictly with manifest, then it opens the question about "passable
add-ons" that are really Python 2 inside but manifest says otherwise. This
But now we're creating the opposite problem, wherein the code passes Python 3 compatibility, so we ignore the fact that the manifest declares it incompatible. That makes for non-passable add-ons, that are considered passable-but-not-working. That is a nonsensical situation from an end-user point of view.

If an author specifies a compatibility range, and we want everyone to start doing that promptly, shouldn't we honor it first and foremost?

If an author does specify a compatibility range not including 2019.3, it shouldn't matter if his code is compatible with 2019.3. Obviously he thinks the add-on is not Py3 ready, and if the manifest, which is part of the add-on, is not compatible with Py3 (which it isn't if its compatibility range doesn't include 2019.3), then the whole add-on is effectively not ready for 2019.3, and should be considered Py3 incompatible.

Now, if we want to say "it works, but he's not maintaining his manifest", then we do a community take over and manually update the add-on. But that's a different situation than what we're talking about here. If the add-on is abandoned, and we want to maintain it until the original author comes back, and update his manifest for him, then that's one thing. But if the add-on is going to remain under the control of its current maintainer, then we have to respect the manifest that he chose to include.

Going the other direction: if an author declares by manifest that an add-on is 2019.3 compatible, if we aren't going to require a code review to prove it (a re-review), then we should accept the manifest at face value until users start reporting problems with the add-on, at which point it becomes an add-on with an invalid manifest, fails review status, and gets de-listed from the website.

I do not understand separating the manifest from the sourcecode. In the case of add-ons, packaging is an integral part of the add-on itself, and so everything in the package that is not documentation or data, by definition has to be source, and thus has to be compatible or not. I do not see it as reasonable, to separate compatibility of the manifest from compatibility of the add-on it represents, if authors are ever to consider manifest accuracy important.

That's my opinion, anyway.

(manifest is considered but not enforced because there are add-ons with no
compatibility range specified). Eventually we will need to enforce
compatibility range in the manifest (it isn't enforced strictly at the
moment to give time for authors to update their mindset), especially once
How long has compat range been a thing? It's been over a year, right? Eventually has come. We should start enforcing it along with 2019.3. As a high-ranking Microsoft dev said when introducing non-backward-compatible features in Windows many years ago: if you're going to break some things, break them all at once and get it over with.

Just as authors are being contacted to update their codebases, they should be contacted to update their manifest compat ranges.

Luke

Join nvda-addons@nvda-addons.groups.io to automatically receive all group messages.