gtristan commented on code in PR #2019:
URL: https://github.com/apache/buildstream/pull/2019#discussion_r2186699367
##########
src/buildstream/_pluginfactory/pluginoriginpip.py:
##########
@@ -72,7 +72,7 @@ def get_plugin_paths(self, kind, plugin_type):
reason="package-not-found",
) from e
- if dist.version not in package.specifier:
+ if not package.specifier.contains(dist.version, prereleases=True):
Review Comment:
@abderrahim writes:
> What I consider to be different between pip and buildstream is that
buildstream doesn't install these packages.
~~Agree~~. Disagree, this is not a defining property.
When I install a package with `pip install <package>` or `pip install .`,
then pip will refuse the install with a sensible error when the required
package is already installed in the target environment with a mismatched
version - this is very similar to what BuildStream is doing.
> So if the user has already installed a prerelease of
buildstream-plugins-community, we should let them use it
Disagree.
The purpose of the version string for plugins in the pip origin is for the
project to make an assertion on it's requirements.
To avoid confusion, this version constraint should follow the pep and refuse
to accept a prerelease if the version constraint expressed would not allow for
a prerelease according to the pep 0440.
**If** it is the case that `buildstream-plugins-community` without any
specific version allowed for prereleases in the past, but are not supposed to
allow for that according to the pep 0440, then I think it would be good to fix
that even if it changes buildstream behavior, and declare that this behavior
was anyway broken until we now fixed it.
As there has been discussion of API addition for a separate flag here, I
would rather argue that it could make sense to have some way of forcing
buildstream to ignore the version specifiers for pip loaded plugins. Possibly
CLI flag or env var, e.g.:
`BST_DANGEROUS_IGNORE_PIP_PLUGIN_VERSION_REQUIREMENTS_IM_TESTING_HERE=1`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
