I built an RPM for RH5 and I'm running into issues with some of the modules I need. First things first, I'm running Ansible 1.9.2. Now, once the RPM is installed, running ansible --version returns the following.
> ansible --version
ansible 1.9.2
configured module search path = None
One of the modules I need is Hipchat, which is throwing an SSL error.
PROTOCOL = ssl.PROTOCOL_TLSv1
NameError: name 'ssl' is not defined
Now, if I set PYTHONPATH to ~/ansible/lib everything works fine. ~ansible is a 1.9 copy from source. My RPM installs the Ansible libraries into /usr/lib/python2.6/site-packages/ansible. So if I point PYTHONPATH to that path, my module doesn't work and it doesn't show what I normally see below.
ansible 1.9.2 (stable-1.9 b70caac618) last updated 2015/06/05 15:22:40 (GMT-400)
lib/ansible/modules/core: (detached HEAD 618806aeeb) last updated 2015/03/04 12:39:45 (GMT -400)
lib/ansible/modules/extras: (detached HEAD 945da71ce4) last updated 2015/03/04 12:39:53 (GMT -400)
v2/ansible/modules/core: (detached HEAD 34784b7a61) last updated 2015/03/04 12:40:03 (GMT -400)
v2/ansible/modules/extras: (detached HEAD 650d740a3a) last updated 2015/03/04 12:40:10 (GMT -400)
configured module search path = None
Python 2.6 does not have built-in SSL support. You need to install PyOpenSSL from your distribution packages.
Adding SSL support to Python 2.6
https://pyopenssl.readthedocs.org/en/stable/
Related
I've been updating an Ansible project, and as part of that I tried to update an assertion about the Ansible version:
- name: Check Ansible version
assert:
that:
- ansible_version.major == 2 and ansible_version.minor >= 5
I figured the version corresponded to the version of the ansible-core package installed, but that doesn't seem to be the case: it's installing ansible-core 2.12.3 and ansible 5.5.0, but changing the assertion to ansible_version.major == 2 and ansible_version.minor >= 12 results in a failure. If ansible_version corresponds to neither version, what does it correspond to?
The project is still using Python 3.6 (don't worry, upgrading it is on the way), which is no longer supported:
[DEPRECATION WARNING]: Ansible will require Python 3.8 or newer on the controller starting with Ansible 2.12. Current version: 3.6.9 (default, Dec 8 2021, 21:08:43) [GCC 8.4.0]. This feature will be removed from ansible-core in version 2.12.
I was wondering why that was an error rather than a warning, considering I'm actually running Ansible (core) 2.12. But the very next line indicates that core 2.12 is capable of running with an older core:
ansible-playbook [core 2.11.9]
SOLVED (see answer)
Problem
I've followed the instalation guide proposed at "https://www.rock-robotics.org/documentation/installation.html" .I'm having an error while installing "rock-robotics" I tried at first in my lighter distribution "Lubuntu" and now I'm trying in "Ubuntu 18.04 LTS" and it happens again, I'm getting crazy with this and the very problem is that I need this package to develop my degree final thesis. Please I need help on this matter, at the end you can see the full output when I run $sudo sh bootstrap.sh (I tried both of the bootstraps suggested and both of them give me the same problem) and here you have the output lines of the error message:
configuring CMake for base/orogen/std configured CMake for tools/pocolog_cpp ERROR: got an error processing base/orogen/std, waiting for pending jobs to end updated environment Command failed base/orogen/std(/home/emi/rock-robotics/base/orogen/std): failed in configure phase
'cmake -DCMAKE_INSTALL_PREFIX=/home/emi/rock-robotics/install -DCMAKE_MODULE_PATH= -DCMAKE_PREFIX_PATH=/home/emi/rock-robotics/install;/home/emi/rock-robotics/tools/orogen
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Release -DROCK_TEST_ENABLED=OFF /home/emi/rock-robotics/base/orogen/std' returned status 1
see /home/emi/rock-robotics/install/log/base/orogen/std-configure.log for details
last 10 lines are:
-- Checking for module 'orocos-rtt-corba-gnulinux>=2.1.0'
-- No package 'orocos-rtt-corba-gnulinux' found
CMake Error at .orogen/config/FindOrocosCORBA.cmake:8 (MESSAGE):
RTT has not been built with CORBA support
Call Stack (most recent call first):
.orogen/typekit/transports/corba/CMakeLists.txt:4 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/emi/rock-robotics/base/orogen/std/build/CMakeFiles/CMakeOutput.log".
FULL-OUTPUT
--2020-06-24 12:02:16-- http://rock-robotics.org/master/autoproj_bootstrap
Resolviendo rock-robotics.org (rock-robotics.org)... 37.17.224.128
Conectando con rock-robotics.org (rock-robotics.org)[37.17.224.128]:80... conectado.
Petición HTTP enviada, esperando respuesta... 301 Moved Permanently
Ubicación: https://rock-robotics.org/master/autoproj_bootstrap [siguiente]
--2020-06-24 12:02:17-- https://rock-robotics.org/master/autoproj_bootstrap
Conectando con rock-robotics.org (rock-robotics.org)[37.17.224.128]:443... conectado.
Petición HTTP enviada, esperando respuesta... 301 Moved Permanently
Ubicación: https://www.rock-robotics.org/master/autoproj_bootstrap [siguiente]
--2020-06-24 12:02:17-- https://www.rock-robotics.org/master/autoproj_bootstrap
Resolviendo www.rock-robotics.org (www.rock-robotics.org)... 185.199.110.153, 185.199.111.153, 185.199.109.153, ...
Conectando con www.rock-robotics.org (www.rock-robotics.org)[185.199.110.153]:443... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 30078 (29K) [application/octet-stream]
Guardando como: “autoproj_bootstrap”
autoproj_bootstrap 100%[===================>] 29,37K --.-KB/s en 0,03s
2020-06-24 12:02:17 (906 KB/s) - “autoproj_bootstrap” guardado [30078/30078]
Which protocol do you want to use to access rock-core/buildconf.git on github.com? [git|ssh|http] (default: http)
Detected 'gem' to be /usr/bin/gem2.5
Detected bundler at /home/emi/.local/share/autoproj/gems/ruby/2.5.0/bin/bundle
Installing autoproj in /home/emi/.local/share/autoproj/gems/ruby/2.5.0
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and
installing your bundle as root will break this application for all non-root
users on this machine.
[DEPRECATED] The --binstubs option will be removed in favor of `bundle binstubs`
Fetching gem metadata from https://rubygems.org/......
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies...
Using rake 12.3.3
Using equatable 0.5.0
Using tty-color 0.4.3
Using pastel 0.7.2
Using tty-cursor 0.5.0
Using necromancer 0.4.0
Using timers 4.3.0
Using tty-screen 0.6.5
Using wisper 2.0.1
Using tty-reader 0.2.0
Using tty-prompt 0.15.0
Using facets 3.1.0
Using utilrb 3.0.1
Using autobuild 1.20.0
Using backports 3.18.1
Using bundler 2.1.4
Using concurrent-ruby 1.0.5
Using ffi 1.13.1
Using rb-inotify 0.10.1
Using thor 0.20.3
Using tty-spinner 0.8.0
Using xdg 2.2.5
Using autoproj 2.12.1
Bundle complete! 2 Gemfile dependencies, 23 gems now installed.
Bundled gems are installed into `/home/emi/.local/share/autoproj/gems`
starting the newly installed autoproj for stage2 install
saving temporary env.sh and .autoproj/env.sh
running 'autoproj envsh' to generate a proper env.sh
[DEPRECATED] `Bundler.with_clean_env` has been deprecated in favor of `Bundler.with_unbundled_env`. If you instead want the environment before bundler was originally loaded, use `Bundler.with_original_env` (called at /home/emi/rock-robotics/.autoproj/bin/autoproj:8)
Which prepackaged software (a.k.a. 'osdeps') should autoproj install automatically (all, none or a comma-separated list of: os gem pip) ?
The software packages that autoproj will have to build may require other
prepackaged softwares (a.k.a. OS dependencies) to be installed (RubyGems
packages, packages from your operating system/distribution, ...). Autoproj
is able to install those automatically for you.
Advanced users may want to control this behaviour. Additionally, the
installation of some packages require administration rights, which you may
not have. This option is meant to allow you to control autoproj's behaviour
while handling OS dependencies.
* if you say "all", it will install all packages automatically.
This requires root access thru 'sudo'
* if you say "pip", only the Python packages will be installed.
Installing these packages does not require root access.
* if you say "gem", only the Ruby packages will be installed.
Installing these packages does not require root access.
* if you say "os", only the OS-provided packages will be installed.
Installing these packages requires root access.
* if you say "none", autoproj will not do anything related to the
OS dependencies.
Finally, you can provide a comma-separated list of pip gem and os.
As any configuration value, the mode can be changed anytime by calling
autoproj reconfigure
Finally, the "autoproj osdeps" command will give you the necessary information
about the OS packages that you will need to install manually.
So, what do you want ? (all, none or a comma-separated list of: os gem pip) [all]
Would you like autoproj to keep apt packages up-to-date? [yes]
updated environment
running 'autoproj osdeps' to re-install missing gems
[DEPRECATED] `Bundler.with_clean_env` has been deprecated in favor of `Bundler.with_unbundled_env`. If you instead want the environment before bundler was originally loaded, use `Bundler.with_original_env` (called at /home/emi/rock-robotics/.autoproj/bin/autoproj:8)
updated environment
Command finished successfully at 2020-06-24 12:02:30 +0200 (took 1 sec)
The current directory is not empty, continue bootstrapping anyway ? [yes]
checked out autoproj main configuration
autoproj bootstrap successfully finished
To further use autoproj and the installed software, you
must add the following line at the bottom of your .bashrc:
source /home/emi/rock-robotics/env.sh
WARNING: autoproj will not work until your restart all
your consoles, or run the following in them:
$ source /home/emi/rock-robotics/env.sh
To import and build the packages, you can now run
aup
amake
The resulting software is installed in
/home/emi/rock-robotics/install
How should I interact with github.com (git, http, ssh)
If you give one value, it's going to be the method used for all access
If you give multiple values, comma-separated, the first one will be
used for pulling and the second one for pushing. An optional third value
will be used to pull from private repositories (the same than pushing is
used by default) [http,ssh]
operating system: ubuntu,debian - 18.04,18.04.4,lts,bionic,beaver
updating bundler
updating autoproj
bundler: connected to https://rubygems.org/
already up-to-date autoproj main configuration
checking out git:https://github.com/rock-core/package_set.git interactive=false push_to=git#github.com:/rock-core/package_set.git repository_id=github:/rock-c checked out git:https://github.com/rock-core/package_set.git interactive=false push_to=git#github.com:/rock-core/package_set.git repository_id=github:/rock-core/package_set.git retry_count=10
Which flavor of Rock do you want to use ?
Stay with the default ('master') if you want to use Rock on the most recent
distributions (Ubuntu 16.04 and later). Use 'stable' only for
now officially unsupported distributions (Ubuntu 14.04) [master]
Do you want to activate python? [no]
checking out git:https://github.com/rock-core/rock-package_set.git interactive=false push_to=git#github.com:/rock-core/rock-package_set.git repository_id=gith checked out git:https://github.com/rock-core/rock-package_set.git interactive=false push_to=git#github.com:/rock-core/rock-package_set.git repository_id=github:/rock-core/rock-package_set.git retry_count=10
checking out git:https://github.com/rock-tutorials/tutorials-package_set.git interactive=false push_to=git#github.com:/rock-tutorials/tutorials-package_set.gi checked out git:https://github.com/rock-tutorials/tutorials-package_set.git interactive=false push_to=git#github.com:/rock-tutorials/tutorials-package_set.git repository_id=github:/rock-tutorials/tutorials-package_set.git retry_count=10
checking out git:https://github.com/orocos-toolchain/autoproj.git interactive=false push_to=git#github.com:/orocos-toolchain/autoproj.git repository_id=github checked out git:https://github.com/orocos-toolchain/autoproj.git interactive=false push_to=git#github.com:/orocos-toolchain/autoproj.git repository_id=github:/orocos-toolchain/autoproj.git retry_count=10
WARN: osdeps definition for cmake, previously defined in /home/emi/.local/share/autoproj/gems/ruby/2.5.0/gems/autoproj-2.12.1/lib/autoproj/default.osdeps overridden by /home/emi/rock-robotics/autoproj/remotes/rock.core/rock.osdeps:
WARN: resp. apt-dpkg: cmake
WARN: osdep: build-essential
WARN: and apt-dpkg: cmake
Do you need compatibility with OCL ? (yes or no)
New Rock users that don't need backward compatibility with legacy Orocos components
probably want to say 'no'. Otherwise, say 'yes'.
Saying 'yes' will significantly impact compilation time and the size of the resulting binaries
Please answer 'yes' or 'no' [no]
the target operating system for Orocos/RTT (gnulinux, xenomai, or macosx) [gnulinux]
which CORBA implementation should the RTT use ?
Answer "none" to disable CORBA, otherwise pick either tao or omniorb [omniorb] "none"
invalid value: invalid value '"none"', accepted values are 'none', 'tao', 'omniorb' (without the quotes)
which CORBA implementation should the RTT use ?
Answer "none" to disable CORBA, otherwise pick either tao or omniorb [omniorb] none
checked out base/templates/cmake_vizkit_widget
checked out base/orogen/std
checked out base/console_bridge
checked out base/numeric
checked out base/logging
checked out base/templates/bundle
checked out base/templates/vizkit3d_plugin
checked out base/templates/ruby_lib
checked out base/orogen/types
checked out base/templates/cmake_lib
checked out base/scripts
checked out base/cmake
checked out bundles/rock
checked out drivers/orogen/aggregator
checked out bundles/common_models
checked out drivers/orogen/iodrivers_base
checked out drivers/aggregator
checked out drivers/iodrivers_base
checked out drivers/orogen/transformer
checked out drivers/transformer
checked out base/types
checked out perception/frame_helper
checked out perception/jpeg_conversion
checked out gui/osgviz
checked out tools/log_tools
checked out gui/rock_webapp
checked out gui/vizkit3d
checked out tools/logger
tools/class_loader: checking out branch indigo-devel
checked out gui/rock_widget_collection
checked out tools/class_loader
checked out tools/orogen_metadata
checked out gui/vizkit
checked out tools/pocolog2msgpack
checked out tools/pocolog_cpp
checked out tools/pocolog
checked out tools/telemetry
checked out base/templates/doc
checked out tools/rest_api
checked out rtt_typelib
checked out utilrb
checked out tools/orocos.rb
checked out orogen
checked out tools/metaruby
checkout of tools/syskit failed, deleting the source directory /home/emi/rock-robotics/tools/syskit and retrying (1/10)
checkout of tools/msgpack-c failed, deleting the source directory /home/emi/rock-robotics/tools/msgpack-c and retrying (1/10)
checked out tools/syskit
tools/msgpack-c: resetting branch master to 83a82e3eb512b18d4149cabb7eb43c7e8bc081af
checked out tools/msgpack-c
WARN: tools/msgpack-c from rock.core does not have a manifest
checkout of tools/service_discovery failed, deleting the source directory /home/emi/rock-robotics/tools/service_discovery and retrying (1/10)
checkout of typelib failed, deleting the source directory /home/emi/rock-robotics/tools/typelib and retrying (1/10)
checkout of tools/roby failed, deleting the source directory /home/emi/rock-robotics/tools/roby and retrying (1/10)
checkout of external/sisl failed, deleting the source directory /home/emi/rock-robotics/external/sisl and retrying (1/10)
checked out typelib
typelib: using the castxml importer
checked out tools/service_discovery
checked out external/sisl
checked out tools/roby
checkout of rtt failed, deleting the source directory /home/emi/rock-robotics/tools/rtt and retrying (1/10)
checked out rtt
building initial autoproj import log, this may take a while
bundler: connected to https://rubygems.org/
updated environment
Command finished successfully at 2020-06-24 12:08:47 +0200 (took 6 mins 9 secs)
bundler: connected to https://rubygems.org/
updated environment
Command finished successfully at 2020-06-24 12:08:52 +0200 (took 3 secs)
operating system: ubuntu,debian - 18.04,18.04.4,lts,bionic,beaver
WARN: osdeps definition for cmake, previously defined in /home/emi/.local/share/autoproj/gems/ruby/2.5.0/gems/autoproj-2.12.1/lib/autoproj/default.osdeps overridden by /home/emi/rock-robotics/autoproj/remotes/rock.core/rock.osdeps:
WARN: resp. apt-dpkg: cmake
WARN: osdep: build-essential
WARN: and apt-dpkg: cmake
WARN: tools/msgpack-c from rock.core does not have a manifest
typelib: using the castxml importer
configured CMake for tools/msgpack-c
built tools/msgpack-c
installed tools/msgpack-c
configured CMake for rtt
built rtt (10 warnings)
set up Ruby package utilrb
installed rtt
configured CMake for external/sisl
set up Ruby package tools/metaruby
configured CMake for typelib
set up Ruby package tools/roby
built typelib (2 warnings)
set up Ruby package base/scripts
installed typelib
built external/sisl (165 warnings)
set up Ruby package tools/pocolog
configured CMake for rtt_typelib
installed external/sisl
built rtt_typelib
configured CMake for base/cmake
installed rtt_typelib
built base/cmake
set up Ruby package orogen
installed base/cmake
set up Ruby package tools/log_tools
configured CMake for tools/orogen_metadata
configured CMake for gui/osgviz
built tools/orogen_metadata
configured CMake for base/logging
built gui/osgviz (6 warnings)
installed tools/orogen_metadata
installed gui/osgviz
built base/logging
configured CMake for gui/vizkit3d
built gui/vizkit3d (7 warnings)
installed base/logging
installed gui/vizkit3d
configured CMake for tools/service_discovery
configured CMake for base/console_bridge
configured CMake for base/types
built tools/service_discovery
installed tools/service_discovery
built base/types (3 warnings)
built base/console_bridge
generated oroGen base/orogen/std
installed base/types
installed base/console_bridge
configuring CMake for base/orogen/std
configured CMake for tools/pocolog_cpp
ERROR: got an error processing base/orogen/std, waiting for pending jobs to end
updated environment
Command failed
base/orogen/std(/home/emi/rock-robotics/base/orogen/std): failed in configure phase
'cmake -DCMAKE_INSTALL_PREFIX=/home/emi/rock-robotics/install -DCMAKE_MODULE_PATH= -DCMAKE_PREFIX_PATH=/home/emi/rock-robotics/install;/home/emi/rock-robotics/tools/orogen -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Release -DROCK_TEST_ENABLED=OFF /home/emi/rock-robotics/base/orogen/std' returned status 1
see /home/emi/rock-robotics/install/log/base/orogen/std-configure.log for details
last 10 lines are:
-- Checking for module 'orocos-rtt-corba-gnulinux>=2.1.0'
-- No package 'orocos-rtt-corba-gnulinux' found
CMake Error at .orogen/config/FindOrocosCORBA.cmake:8 (MESSAGE):
RTT has not been built with CORBA support
Call Stack (most recent call first):
.orogen/typekit/transports/corba/CMakeLists.txt:4 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/emi/rock-robotics/base/orogen/std/build/CMakeFiles/CMakeOutput.log".
Finaly I solved it following some advices of the rock-robotics team. I used another bootstrap.sh and also accepted the corba support, the complete process was:
mkdir rock-workspace
cd rock-workspace
wget https://www.rock-robotics.org/bootstrap.sh
sh bootstrap.sh
Then the answers to the critical questions while bootstrapping:
Do you need compatibility with OCL ? (yes or no)
New Rock users that don't need backward compatibility with legacy Orocos components
probably want to say 'no'. Otherwise, say 'yes'.
Saying 'yes' will significantly impact compilation time and the size of the resulting binaries
Please answer 'yes' or 'no' [no] no
the target operating system for Orocos/RTT (gnulinux, xenomai, or macosx) [gnulinux] gnulinux
which CORBA implementation should the RTT use ?
Answer "none" to disable CORBA, otherwise pick either tao or omniorb [omniorb] omniorb
so the answers were no, gnulinux and omniorb
OS : 'CentOS 6.5
'
ElasticSearch version : '2.3.0'
Master's puppet version: '3.8.7'
Client's puppet version : '3.7.4'
Base module version before upgrade : '0.10.2'
Base module version after upgrade : '5.1.0'
Error: could not retrieve catalog from remote server: Error 400 on
SERVER: invalid parameter elasticsearch_package_name on
Elasticsearch_plugin[license] at
/etc/puppet/environments/production/modules/elasticsearch/manifests/plugin.pp:169
on node bla-test01.dom'
Hi,
This error started after we upgraded our Elasticsearch's base (Official from puppet forge) module from version '0.10.2' to '5.1.0'. Our puppet module of elasticsearch worked just fine before the upgrade.
Since the upgrade this error occurred whenever puppet ran on our nodes.
After we saw this case we tried to restart our puppetserver service. Since the restart, the error occurs once every 3-4 runs of puppet and we have no idea why.
Looking at the elastic/elasticsearch module which is the one you seem to be using i can see that the elastic_plugin custom type did not have the elasticsearch_package_name parameter in version 0.11.0 however the 5.1.0 version does. This looks to me that you may have updated the module on the system but have not restarted the puppet server so it still has the 0.11.0 custom type/provider ruby files loaded.
Restart the puppet master server and see if that fixes the issue
I need to make use of python's mitmproxy. I have installed it successfully. However when I run mitmproxy command on my terminal it gives me a stack trace like the below :
File "/usr/local/bin/mitmproxy", line 9, in load_entry_point('mitmproxy==0.13', 'console_scripts','mitmproxy'()
File "/Library/Python/2.7/site-packages/pkg_resources/init.py", line 558, in load_entry_pointreturn get_distribution(dist).load_entry_point(group, name)
File "/Library/Python/2.7/site-packages/pkg_resources/init.py", line 2682, in load_entry_point return ep.load()
File "/Library/Python/2.7/site-packages/pkg_resources/init.py", line 2355, in load return self.resolve()
File "/Library/Python/2.7/site-packages/pkg_resources/init.py", line 2361, in resolve module = import(self.module_name, fromlist=['name'], level=0)
File "/Library/Python/2.7/site-packages/libmproxy/main.py", line 7, in from . import version, cmdline
File "/Library/Python/2.7/site-packages/libmproxy/cmdline.py", line 5, in from netlib import http
File "/Library/Python/2.7/site-packages/netlib/http.py", line 7, in from . import odict, utils, tcp, http_status
File "/Library/Python/2.7/site-packages/netlib/tcp.py", line 26, in 'TLSv1.2': SSL.TLSv1_2_METHOD, AttributeError: 'module' object has no attribute 'TLSv1_2_METHOD'
I tried debugging the issue through some Googling and looks like I needed to upgrade my pyOpenSSL.
To know the current version of my PyOpen SSL I did the following on the Python prompt and got the ouptut as shown below to be 0.13:
>>> import OpenSSL
>>> print OpenSSL.__version__
0.13
So I tried upgrading the my pyOpenSSL using the below :
sudo pip install --upgrade pyOpenSSL
ans successfully did so, as when I ran the above again I received the following in the first line of the output :
Requirement already up-to-date: pyOpenSSL in /Library/Python/2.7/site-packages
Just to cross verify I went to the above path and found the PyOpenSSL dir as PyOpenSSL-0.15.1.dist-info. So am guessing PyOpenSSL was actually upgraded to the latest version.
However, when I ran the below on Python prompt again I received the version again as 0.13. Ideally I was expecting it to give the updated version now.
>>> import OpenSSL
>>> print OpenSSL.__version__
0.13
Some blogs suggested that if I have a virtualevn installed, it might interfere with the above. So I uninstalled virtualenv as well using
sudo pip uninstall virtualenv
I am still not able to get mitmproxy running. And when I run mitmproxy, I still get the same error as above.
Please let me know what am I missing and how to get mitmproxy running.
So it happens yet again. :P I could figure out the problem with the above approach and the solution to it as well on my own - OF COURSE - with the help of some friends and blogs !
So appears that the problem was actually because of MANY out-dated dependencies : -
Outdated OpenSSL -
current version displayed using OpenSSL version -a
Awesome help found # http://javigon.com/2014/04/09/update-openssl-in-osx/ to update OpenSSL and from a friend (https://anantshri.info/) who pointed out the issue itself initially.
Outdated pyOpenSSL - upgraded using the below which of course upgraded the same.
sudo pip install --upgrade pyOpenSSL
Then why was the below still showing an outdated version ?
import OpenSSL
print OpenSSL.version
0.13
because there were 2 different OpenSSLs in the system. One that was installed by pip and the other that was by default present in OSX. Again awesome help found # https://github.com/pyca/pyopenssl/issues/128
some useful commands that helper were :
pip show pyOpenSSL - gives as output :
Name: pyOpenSSL
Version: 0.15.1
Location: /Library/Python/2.7/site-packages
as part of the output - indicating that the OpenSSL installed using pip is actually 0.15.1
cross verify using :
ls /Library/Python/2.7/site-packages/ | grep OpenSSL - gives as output:
pyOpenSSL-0.15.1.dist-info
Now the path below also had another copy of OpenSSL :
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/OpenSSL and cat version.py in the above dir gave the below as part of output :
version = '0.13.1'
indicating that the cause of the issue with the import statement showing the outdated python version.
And the above itself was the root cause for mitmproxy also not working
because mitmproxy was unable to use the latest version on OpenSSL.
So solved the problem by just replacing the OpenSSL in the above path (which was outdated) with the updated one from /Library/Python/2.7/site-packages/
where
cat ./OpenSSL/version.py gave as output (once again just to cross-verify)
version = '0.15.1'
And now the import statement reported the right version of OpenSSL.
Uninstalled mitmproxy using sudo pip uninstall mitmproxy - successfully uninstalled. Also uninstalled virtualenv. (not sure of the above 2 was required !)
Reinstalled mitmproxy as sudo pip install mitmproxy - Successfully done !
And ran mitmproxy now from the terminal wihtout a glitch ! :)
I got Python 2.7.8 installed on my Win7 machine, which comes with pip already pre-installed. I'm successfully able to install new packages from pip and now I need to add custom repository url to the install list of pip
To do so I need to modify pip.ini which is in %APPDATA%\pip\pip.ini according to the Official Manual
However there are no pip folder anywhere (not in Roaming, not in Local, not in LocalLow)
nor there exists PyPa folder in: C:\ProgramData\PyPA\pip\pip.conf
Could you tell me where do i search for pip.ini? how to add foreign repo to the install list?
Instead of checking a list of well-known locations, you can ask pip to list the valid locations:
pip config -v list
Fun fact
On the same machine, with the same pip version, the valid locations can vary based on the actual Python version.
Environment: Win 7 x64, the HOME environment variable is set to D:\Home
Python 3.7.3:
> pip config -v list
For variant 'global', will try loading 'C:\ProgramData\pip\pip.ini'
For variant 'user', will try loading 'D:\Home\pip\pip.ini'
For variant 'user', will try loading 'C:\Users\foobar\AppData\Roaming\pip\pip.ini'
For variant 'site', will try loading 'C:\Python37\pip.ini'
Python 3.8.0:
> pip config -v list
For variant 'global', will try loading 'C:\ProgramData\pip\pip.ini'
For variant 'user', will try loading 'C:\Users\foobar\pip\pip.ini'
For variant 'user', will try loading 'C:\Users\foobar\AppData\Roaming\pip\pip.ini'
For variant 'site', will try loading 'C:\Python38\pip.ini'
Finally got it sorted.
Apparently for Windows users pip.ini config file is not created, however can be added manually!
just create new %APPDATA%\pip\pip.ini and content of custom repository:
[install]
find-links = https://<login>:<password>#your.repo.com/custom/url
Reference: https://pip.pypa.io/en/stable/user_guide/#config-file
A bit late, but for reference:
Try adding the pip.ini file in %USERPROFILE%\pip\pip.ini (usually: C:\Users\<username>\pip\pip.ini).
On windows pip.exe looks for "pip.ini" in this order:
C:\ProgramData\pip\pip.ini
C:\Users\<username>\pip\pip.ini
C:\Users\<username>\AppData\Roaming\pip\pip.ini
It's been 7 years, and I think there's now a better answer for most people -- but it does depend on version of pip. For the most recent pips I'm using:
$ pip config -v debug
lists where it's looking and you can decide which location is
most useful for what you've got in mind. It does look like a fairly recent
change: On a year-old docker image I had with pip 20.1
I got "ERROR: Need an action (edit, get, list, set, unset) to
perform." On that system, pip config -v list gave a list of files it would try, this is supposed to be 'global', 'user' or 'site' variants of pip.ini locations.
For Windows 10, for pip 21.2.4 on both 3.9.6 and 3.6.8, I get response below with pip config -v debug, while pip config -v list is silent (unless a pip.ini is found).
global:
C:\ProgramData\pip\pip.ini, exists: False
site:
c:\py\myvenv\pip.ini, exists: False
user:
C:\Users\myname\pip\pip.ini, exists: False
C:\Users\myname\AppData\Roaming\pip\pip.ini, exists: False
From a downloaded image I got from dockerhub in June 2021 with pip 21.2.2 and python 3.6.10:
pip config -v debug
env_var:
env:
global:
/etc/xdg/pip/pip.conf, exists: False
/etc/pip.conf, exists: True
global.extra-index-url: http://trynexs:8081/repository/repo_group/simple
site:
/usr/local/pip.conf, exists: False
user:
/home/tanhauser/.pip/pip.conf, exists: False
/home/tanhauser/.config/pip/pip.conf, exists: False
Pip changed the location of the config file in windows starting in pip 6.0 the pip config docs explain the location of the config files as follows.
pip --version >= 6 (as of version 18.1 hasn't changed again yet)
%APPDATA%\pip\pip.ini
pip --version < 6
%HOME%\pip\pip.ini
Inside a virtual env
%VIRTUAL_ENV%\pip.ini
Site-wide win7+ (same as of win10)
C:\ProgramData\pip\pip.ini
Site-wide winxp (note windows vista side wide not supported)
C:\Documents and Settings\All Users\Application Data\pip\pip.ini
NOTE: If multiple configuration files are found by pip then they are combined in the following order:
The site-wide file is read
The per-user file is read
The virtualenv-specific file is read
Also pip added a config command starting in pip 10.
pip config --help
I know this is a bit late, however, this post is high on the rankings when searching. Inside a virtual environment pip.ini can also be in the root of the virtual environment. From the docs and https://pip.pypa.io/en/stable/user_guide/?highlight=pip.ini#configuration
Inside a virtualenv:
On Unix and macOS the file is $VIRTUAL_ENV/pip.conf
On Windows the file is: %VIRTUAL_ENV%\pip.ini
All the answers are partially wrong and right.
It depends on how your system is configured. The only way (for me) to find out was to patch site-packages/pip/locations.py at the point where site_config_files is assigned (around line 120 for pip 9.0.1)
print('########## ' + str(site_config_files))
and then run pip search foo
On my system it printed ########## ['C:\\ProgramData\\pip\\pip.ini'], of which location I assumed I could not create/edit. But it just worked.
Btw, for my system %APPDATA% points to C:\Users\MYUSER\AppData\Roaming, which is not looked at when running pip on my system.
Rather than guessing first check if you have any default global/local config which is read by pip with the below command:
pip config list
This will give all details of the default config loaded by python.
If the above command doesn't give any output please try to find where pip tries to find for the global config file with the below command:
pip config --editor <path to editor of your choice> edit
The above command will open the config file which pip reads by default or else it will give an error saying that the file doesn't exist.
If there's an error please go ahead and create the exact directory and file structure as show in the error. Once the file has been created please make your changes e.g.
[global]
cert = /path/to/base64/ssl/certificate.pem
proxy = http://username:password#ipaddress:port
Save the file and please try to check (the above mentioned check command) if the configs are loaded by pip or not.
For more info please follow pip config documentation
Make sure you acually have a pip.ini file, not pip.ini.txt.
For me (Windows 8, pip 9.0.1, python 3.5.3), the correct path was
c:\Users\<UserName>\.pypirc <- sic!, even on windows
Windows 10:
I had to create 'pip' directory inside
C:\Users\UserName\AppData\Roaming\
then create pip.ini file inside that 'pip' directory:
C:\Users\<username>\AppData\Roaming\pip\pip.ini
No other location worked for me.
For Windows, python will load the config from path below. So, if pip.ini file is not exist in these paths you can create the new file by refer these path depend on environment scopes (global, user & site) that you need python execute.
For variant 'global', will try loading 'C:\ProgramData\pip\pip.ini'
For variant 'user', will try loading 'C:\Users\MyName\pip\pip.ini'
For variant 'user', will try loading 'C:\Users\MyName\AppData\Roaming\pip\pip.ini'
For variant 'site', will try loading 'c:\python39-32\pip.ini'
By the way, you can check the paths as above by
pip config -v list
On a Windows 10 machine with multiple users I used this:
c:\users\all users\pip\pip.ini
Using pip version 22.3.1 with python version 3.10.4..