Neon: name 'pip' is not defined #53570
Comments
|
The versions report shows Python 3.6.8 but the tracebacks refer to python 2.7. What are the outputs of |
Akm0d
added
Bug
|
I think I was able to reproduce it on both versions of Python, that is why I posted mixed versions. Just did another test:
Minion log: ModuleNotFoundError: No module named 'pip'salt --versions-reportsalt minion1 test.versions_report
|
|
When I bootstrap the |
Akm0d
removed
the
Pending-Discussion
|
The -P option should make sure pip and it's dependencies are installed. Maybe this is an issue for the salt-boostrap repo? |
|
I agree that it could be an issue with salt-bootstrap. But why it is not reproducible with |
|
Existing unit tests weren't able to detect it because the testing evironment has a lot of preinstalled dependencies, including pip. One possible solution is to have an additional testing environment with no extra deps installed, and run a subset of tests (or a couple of special high-level tests) to ensure that some basic Salt operations can actually work. This would also help to detect (accidentally introduced) new hard dependencies. CC: @s0undt3ch |
|
Unfortunately, we rely on pip to set things up to even run the tests, we could create a separate virtual environment just to test this scenario, but virtualenv will install pip. |
|
Actually, the fix is likely something like: diff --git a/salt/states/pip_state.py b/salt/states/pip_state.py
index b8223e3b9b..eb625ad544 100644
--- a/salt/states/pip_state.py
+++ b/salt/states/pip_state.py
@@ -44,6 +44,19 @@ try:
HAS_PIP = True
except ImportError:
HAS_PIP = False
+
+if HAS_PIP is True:
+ if salt.utils.versions.compare(ver1=pip.__version__,
+ oper='>=',
+ ver2='18.1'):
+ from pip._internal.exceptions import InstallationError # pylint: disable=E0611,E0401
+ elif salt.utils.versions.compare(ver1=pip.__version__,
+ oper='>=',
+ ver2='1.0'):
+ from pip.exceptions import InstallationError # pylint: disable=E0611,E0401
+ else:
+ InstallationError = ValueError
+
# Remove references to the loaded pip module above so reloading works
import sys
pip_related_entries = [
@@ -60,18 +73,6 @@ except ImportError:
if sys_modules_pip is not None:
del sys_modules_pip
-if HAS_PIP is True:
- if salt.utils.versions.compare(ver1=pip.__version__,
- oper='>=',
- ver2='18.1'):
- from pip._internal.exceptions import InstallationError # pylint: disable=E0611,E0401
- elif salt.utils.versions.compare(ver1=pip.__version__,
- oper='>=',
- ver2='1.0'):
- from pip.exceptions import InstallationError # pylint: disable=E0611,E0401
- else:
- InstallationError = ValueError
-
# pylint: enable=import-errorWould you agree @dwoz? A way to test would be to create a virtualenv, uninstall pip, and try to use the pip state againt that virtualenv and see if we didn't get a traceback, of course, the pip state would be unavailable because pip is missing, but it would test this particular issue. |
|
With the release of the packaged 2019.2.1, I am bitten by this bug too. Is there a reason why this shouldn't be fixed as described by #53570 (comment) |
|
It is easy to fix this specific issue (and I have no idea why they didn't fix it, and why it was not considered while backporting the change, and why it wasn't discovered during the 2019.2.1 QA phase). The problem with this approach is that these kinds of issues (new hard dependencies that are invisible to the existing test suite) could appear again. Besides manual QA, I think it is possible to have an automated set of smoke tests that could run in a clean environment without any extra deps installed. |
|
OK, thanks for the quick reply and explanation. As a workaround I will use the 2019.2.0 release for now. |
|
@swinkels Setting the proper fix aside, there is a simple workaround. Just install the
or
|
|
Thanks for the workaround, but it is not so easy in our case. We have a fully automated deployment using Foreman and Salt that installs and fully configures a "bare metal" machine using custom Debian and CentOS repositories. To cut a long story short, it is a bit more work than just install python-pip before we install Salt. |
|
my solution for now: echo '# disabled for now, because of https://github.com/saltstack/salt/issues/53570' > /srv/salt/_states/pip_state.pyOf course only applicable when you do not use the pip state. |
|
Bitten by this bug on Ubuntu 16.04 LTS and 2019.2.1. Actually it first happened when provisioning a new machine today (did not experience it a few days ago). Workaround with installing pip on the target machine works, although that breaks completely the automation and magic that comes with a highstate. I have been searching now actively for a solution - apparently everybody claims "it's not their problem". But pip is not being installed during bootstrap - and it's apparently needed. Or am I completely off here? |
|
@micdobro The bug is fixed in 2019.2.2 |
|
@max-arnold Thanks a lot. We are then scheduling an upgrade. |
|
I guess this could be closed, because Neon is going to be ported on top of the master branch |
Description of Issue
I've been testing some stuff on Neon and got the following traceback:
Immediately after the traceback, I get huge amount of other exceptions:
Collapsed...
Setup
apt-get dist-upgradeapplied)bootstrap-salt.sh -P -f -g https://github.com/saltstack/salt.git -F -c /tmp git neonSteps to Reproduce Issue
Apply the following (simplified) state using
salt XXX state.apply teststateThe same state works just fine on Salt 2019.2.0.
Versions Report
sudo salt-minion --versions-report
The text was updated successfully, but these errors were encountered: