Failing build - Command "python setup.py egg_info" failed with error code 1 about localstack HOT 6 CLOSED

Thanks for reporting. Judging from where the error originates (https://github.com/benoit-pierre/python2-subprocess32/blob/master/setup.py#L9), the pip installation code must at some point get into a state where some Python code is executed/interpreted by a Python 3.x runtime.

Why exactly this is the case is relatively difficult to say because it very much depends on your environment. But we can try to dig a little deeper. First of all we need to understand how your terminal session points to either version of python:

which python
ls -la `which python`

It can be useful to search for the location of your installed Python versions. If you have the locate command installed, you can try the following (alternatively, you can use find):

locate bin/python2.
locate bin/python3.

(No need to post the entire output from the command above, but maybe it helps you extract the main installation folders for Python 2.x and 3.x). Maybe you can also post the relevant content of your PATH environment variable (before posting, make sure to obfuscate any parts that could reveal your username etc):

echo $PATH

Also, can you double-check if there is any custom $PATH handling logic in your ~/.profile, ~/.bash_profile, or ~/.bashrc. For instance, if your ~/.bashrc adds python to the system path, then under certain circumstances a process that calls python in a sub-shell might in fact call a python 3.x subprocess. This can happen if the command that runs python executes in a different shell than bash (for instance sh), which means that this shell will miss the (bash-specific) customizations and hence could fall back to Python 3 instead. This is of course pure speculation, but it could in fact be a possible scenario.

Generally speaking, if you want to avoid Python 2.x vs 3.x problems altogether, it would be advisable to maintain only one version (Python 2.x) and delete the other version. This is not always possible or desired, though, and generally you should be able to run both versions side by side on a single system. By investigating the output of the commands posted above, we may be able to drill down to the root cause of the problem. Thanks

from localstack.

Edit: I just figured out that this issue might have already been fixed in the subprocess32 library (see this pull request: https://github.com/google/python-subprocess32/pull/13/files), but the code has never been released since then. I will look into using a snapshot version of subprocess32, which should fix your issue. Regardless, it would be interesting to find out why this file was executed by Python 3.x in the first place...

from localstack.

Thanks. Upon rechecking the versions, the problem turned out to be the python3 virtualenv which I'd installed at some point, causing /usr/local/bin/virtualenv -> /usr/local/opt/python3/bin/pyvenv.

Replacing that with the correct version fixed the issue.

Closing the issue, as I'm not sure if version checks is a part of the setup.

from localstack.

Thanks for following up on this issue. We have added a patch in 5f0304d to make sure the installation does not fail in the scenario described above.

from localstack.

I have the same error pip installing flask-mongoengine under virtual 'venv' for Python 3.x but it installed with no errors under virtual 'env' for Python 2.x

from localstack.

@popcycle - is your question related to the LocalStack platform? I'm not aware that we are using flask-mongoengine as a dependency.

from localstack.