RFC: remove deprecation of getproperty on Pairs

[KristofferC]

This causes hundred+ of packages (looking at #39448 (comment)) to start giving deprecation warnings by default. The motivation for the feature (#25750) also seems highly speculative so making something disruptive based on that doesn't feel like it is a good tradeoff.

[vtjnash]

It is not necessary to delete the deprecation. It is why we have deprecations, particularly for packages that are buggy.

[KristofferC]

It is not necessary to delete the deprecation. It is why we have deprecations, particularly for packages that are buggy.

Please address the comment in the OP; it is never claimed that it is a necessity. It is claiming that the annoyance it brings for users is not worth the benefit it provides. That trade-off has to always be considered when implementing something, no matter if it is internal or not.

[simeonschaub]

Would just removing the force=true be a reasonable compromise? That way, it would only show up in tests, not regular usage. We don't document the internal fields of Pairs anywhere, so I don't think a deprecation here is unreasonable.

[KristofferC]

The whole point is that

We don't document the internal fields of Pairs anywhere, so I don't think a deprecation here is unreasonable

means there is no need to add a deprecation warning. It is completely arbitrary why this specific field has a deprecation warning and now e.g. PkgEval logs are spammed with this, it will show up in old package versions forever, and making it silent means there is still a performance problem with it and this is not unlikely to be used in hot code. All around, nothing has really been gained and a bunch of pain in the butt has been created.

[simeonschaub]

Can PkgEval just disable deprecation warnings in tests?

means there is no need to add a deprecation warning.

So you think this should just be an error? The problem is that this would be quite disruptive, since a lot of packages rely on this internal detail.

[KristofferC]

So you think this should just be an error?

No, I think nothing should be done. Just like in #41018.

[vtjnash]

How does this compare to #41018? We can restore those named bits if you want, I was probably going to bring them back eventually via compiler features anyways. That contrasts to this PR, where we plan to make this go away permanently in the next release.

[KristofferC]

where we plan to make this go away permanently in the next release.

Are we?

#25750 (comment)

#25750 (comment)

#25750 (comment)

etc.