You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have not held to semver wrt defining the public API or handling deprecations. It may be that only Pants uses PEX via the API, but this is dubious. We should come up with some way for external parties to assess if the API they are using is public so that they can rely on semver for their PEX requirement range.
This was a misfeature added to support a Pants use case, which is implemented another way.
This never worked very robustly:
> To be clear though, there are many corners this will not work for including mismatching abi (python2.7m vs python2.7mu) when the PEX contains platform specific wheels, etc.
If a user only wants to resolve for one interpreter, they should use `--python` or `--interpreter-constraints` with the upcoming `--python-path` flag.
We don't use a proper deprecation due to #584. We'll call attention to this in the release notes.
Although Pants no longer uses any API except the Pex CLI API, the need for semver still exists for CLI changes like adding subcommands 1st class (instead of via the side-door of PEX_TOOLS, etc.).
We have not held to semver wrt defining the public API or handling deprecations. It may be that only Pants uses PEX via the API, but this is dubious. We should come up with some way for external parties to assess if the API they are using is public so that they can rely on semver for their PEX requirement range.
See: https://semver.org/
The text was updated successfully, but these errors were encountered: