The class knows about which pip versions support --process-dependency-links, which
need --no-use-wheel and which are broken altogether and adds/removes these parameters
accordingly or outright reports the broken pip version.
Depending on the pip version pip might first fetch the full index of packages available
on PyPI instead of just directly processing the provided link.
Display corresponding message to user from backend to make sure they don't
think something broke.
Lines taking from the asynchronous processing of stdout/stderr where
left as str, leading to encoding problems when utf8 characters showed
up in the stream and were being interpreted as ascii encoding.
(cherry picked from commit 9373be3)
Old versions of setuptools return a tuple for their
pkg_resources.parse_version method instead of a Version object with
a base_version attribute that we can use to retrieve the base version.
So some manually parsing is needed instead.
OctoPrint's version might be a prerelease version ("...dev<n>"), we
want that to still be able to pass plugin compatibility checks like the
final release version would, so always use the base version of
OctoPrint's current version for comparison during compatibility checks.
Should be valid zip archives/tarballs. Also use only the extension
of an uploaded plugin archive as suffix for the temporary file that's
used for installing it.
(cherry picked from commit a1ff698)
Should be valid zip archives/tarballs. Also use only the extension
of an uploaded plugin archive as suffix for the temporary file that's
used for installing it.
Plugin Manager now internally uses pkg_resources.parse_version and
pkg_resources.parse_requirements to check for version compatibility
with plugins from the repository. That will allow to directly use
the OctoPrint version string once it's PEP440 compatible.
(cherry picked from commit 8eb61a9)
Plugin Manager now internally uses pkg_resources.parse_version and
pkg_resources.parse_requirements to check for version compatibility
with plugins from the repository. That will allow to directly use
the OctoPrint version string once it's PEP440 compatible.
If compatibility information is provided only as a version number it's
prefixed with >= for the check (so stating a compatibility of only
1.2.0 will now make the plugin compatible to all versions that follow
too).
Alternatively the compatibility information may now contain stuff like
">=1.2,<1.3" in which case the plugin will only be shown as compatible
to OctoPrint versions 1.2 and up but not 1.3 or anything above that.
(cherry picked from commit d5692d7)
If compatibility information is provided only as a version number it's
prefixed with >= for the check (so stating a compatibility of only
1.2.0 will now make the plugin compatible to all versions that follow
too).
Alternatively the compatibility information may now contain stuff like
">=1.2,<1.3" in which case the plugin will only be shown as compatible
to OctoPrint versions 1.2 and up but not 1.3 or anything above that.
Doesn't work reliably across pip versions, and adding a special rule for each and every version also isn't fun. Plugin authors will need to use a different approach for pulling in dependencies that are not on pypi during install, e.g. extra install urls or something like that. For now, I give up here ;)
Match against entry_point origins using both package name and package name plus version. If one of those matches (depends on pip version if output will include version or not), it's the plugin we are looking for.
This way we don't need to try to strip a version number from the package name as output by pip without knowing if a version number is included or not.
Some pip invocations return extra info after the Successfully installed
(like "Cleaning up..."). Also, not all packages include a version
number in their package names.
