I installed the Python modules construct and statlib using setuptools:
sudo apt-get install python-setuptools
sudo easy_install statlib
sudo easy_install construct
How do I check their versions from the command line?
Use pip instead of easy_install.
With pip, list all installed packages and their versions via:
pip freeze
On most Linux systems, you can pipe this to grep (or findstr on Windows) to find the row for the particular package you're interested in.
Linux:
pip freeze | grep lxml
lxml==2.3
Windows:
pip freeze | findstr lxml
lxml==2.3
For an individual module, you can try the __version__ attribute. However, there are modules without it:
python -c "import requests; print(requests.__version__)"
2.14.2
python -c "import lxml; print(lxml.__version__)"
Traceback (most recent call last):
File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'version'
Lastly, as the commands in your question are prefixed with sudo, it appears you're installing to the global python environment. I strongly advise to take look into Python virtual environment managers, for example virtualenvwrapper.
You can try
>>> import statlib
>>> print statlib.__version__
>>> import construct
>>> print contruct.__version__
This is the approach recommended by PEP 396. But that PEP was never accepted and has been deferred. In fact, there appears to be increasing support amongst Python core developers to recommend not including a __version__ attribute, e.g. in Remove importlib_metadata.version..
Python >= 3.8:
If you're on Python >= 3.8, you can use a module from the built-in library for that. To check a package's version (in this example construct) run:
>>> from importlib.metadata import version
>>> version('construct')
'4.3.1'
Python < 3.8:
Use pkg_resources module distributed with setuptools library. Note that the string that you pass to get_distribution method should correspond to the PyPI entry.
>>> import pkg_resources
>>> pkg_resources.get_distribution('construct').version
'2.5.2'
Side notes:
Note that the string that you pass to the get_distribution method should be the package name as registered in PyPI, not the module name that you are trying to import. Unfortunately, these aren't always the same (e.g. you do pip install memcached, but import memcache).
If you want to apply this solution from the command line you can do something like:
python -c \
"import pkg_resources; print(pkg_resources.get_distribution('construct').version)"
Use pip show to find the version!
# In order to get the package version, execute the below command
pip show YOUR_PACKAGE_NAME | grep Version
You can use pip show YOUR_PACKAGE_NAME - which gives you all details of package. This also works in Windows.
grep Version is used in Linux to filter out the version and show it.
The better way to do that is:
For the details of a specific package
pip show <package_name>
It details out the package_name, version, author, location, etc.
$ pip show numpy
Name: numpy
Version: 1.13.3
Summary: NumPy: array processing for numbers, strings, records, and objects.
Home-page: http://www.numpy.org
Author: NumPy Developers
Author-email: numpy-discussion#python.org
License: BSD
Location: c:\users\prowinjvm\appdata\local\programs\python\python36\lib\site-packages
Requires:
For more details: >>> pip help
pip should be updated to do this.
pip install --upgrade pip
On Windows the recommended command is:
python -m pip install --upgrade pip
In Python 3 with brackets around print:
>>> import celery
>>> print(celery.__version__)
3.1.14
module.__version__ is a good first thing to try, but it doesn't always work.
If you don't want to shell out, and you're using pip 8 or 9, you can still use pip.get_installed_distributions() to get versions from within Python:
The solution here works in pip 8 and 9, but in pip 10 the function has been moved from pip.get_installed_distributions to pip._internal.utils.misc.get_installed_distributions to explicitly indicate that it's not for external use. It's not a good idea to rely on it if you're using pip 10+.
import pip
pip.get_installed_distributions() # -> [distribute 0.6.16 (...), ...]
[
pkg.key + ': ' + pkg.version
for pkg in pip.get_installed_distributions()
if pkg.key in ['setuptools', 'statlib', 'construct']
] # -> nicely filtered list of ['setuptools: 3.3', ...]
The previous answers did not solve my problem, but this code did:
import sys
for name, module in sorted(sys.modules.items()):
if hasattr(module, '__version__'):
print name, module.__version__
Use dir() to find out if the module has a __version__ attribute at all.
>>> import selenium
>>> dir(selenium)
['__builtins__', '__doc__', '__file__', '__name__',
'__package__', '__path__', '__version__']
>>> selenium.__version__
'3.141.0'
>>> selenium.__path__
['/venv/local/lib/python2.7/site-packages/selenium']
You can try this:
pip list
This will output all the packages with their versions.
Output
In the Python 3.8 version, there is a new metadata module in the importlib package, which can do that as well.
Here is an example from the documentation:
>>> from importlib.metadata import version
>>> version('requests')
'2.22.0'
Some modules don't have __version__ attribute, so the easiest way is check in the terminal: pip list
If the methods in previous answers do not work, it is worth trying the following in Python:
import modulename
modulename.version
modulename.version_info
See Get the Python Tornado version
Note, the .version worked for me on a few others, besides Tornado as well.
First add executables python and pip to your environment variables. So that you can execute your commands from command prompt. Then simply give Python command.
Then import the package:
import scrapy
Then print the version name
print(scrapy.__version__)
This will definitely work.
Assuming we are using Jupyter Notebook (if using Terminal, drop the exclamation marks):
if the package (e.g., xgboost) was installed with pip:
!pip show xgboost
!pip freeze | grep xgboost
!pip list | grep xgboost
if the package (e.g. caffe) was installed with Conda:
!conda list caffe
I suggest opening a Python shell in the terminal (in the Python version you are interested), importing the library, and getting its __version__ attribute.
>>> import statlib
>>> statlib.__version__
>>> import construct
>>> contruct.__version__
Note 1: We must regard the Python version. If we have installed different versions of Python, we have to open the terminal in the Python version we are interested in. For example, opening the terminal with Python 3.8 can (surely will) give a different version of a library than opening with Python 3.5 or Python 2.7.
Note 2: We avoid using the print function, because its behavior depends on Python 2 or Python 3. We do not need it, and the terminal will show the value of the expression.
This answer is for Windows users. As suggested in all other answers, you can use the statements as:
import [type the module name]
print(module.__version__) # module + '.' + double underscore + version + double underscore
But, there are some modules which don't print their version even after using the method above. So, you can simply do:
Open the command prompt.
Navigate to the file address/directory by using cd (file address) where you've kept your Python and all supporting modules installed. If you have only one Python interpreter on your system, the PyPI packages are normally visible in the directory/folder: Python → Lib → site-packages.
use the command "pip install [module name]" and hit Enter.
This will show you a message as "Requirement already satisfied: file address\folder name (with version)".
See the screenshot below for example: I had to know the version of a pre-installed module named "Selenium-Screenshot". It correctly showed as 1.5.0:
Go to terminal like pycharm-terminal
Now write py or python
and hit Enter.
Now you are inside python in the terminal you can try this way:
# import <name_of_the_library>
import kivy
# So if the library has __version__ magic method, so this way will help you
kivy.__version__ # then hit Enter to see the version
# Output >> '2.1.0'
but if the above way not working for you can try this way to know information include the version of the library
pip show module <HERE PUT THE NAME OF THE LIBRARY>
Example:
pip show module pyperclip
Output:
Name: pyperclip
Version: 1.8.2
Summary: A cross-platform clipboard module for Python. (Only handles plain text for now.)
Home-page: https://github.com/asweigart/pyperclip
Author: Al Sweigart
Author-email: al#inventwithpython.com
License: BSD
Location: c:\c\kivymd\virt\lib\site-packages
Requires:
Required-by:
There is another way that could help you to show all the libraries and versions of them inside the project:
pip freeze
# I used the above command in a terminal inside my project this is the output
certifi==2021.10.8
charset-normalizer==2.0.12
docutils==0.18.1
idna==3.3
Kivy==2.1.0
kivy-deps.angle==0.3.2
kivy-deps.glew==0.3.1
kivy-deps.sdl2==0.4.5
Kivy-Garden==0.1.5
kivymd # file:///C:/c/kivymd/KivyMD
Pillow==9.1.0
Pygments==2.12.0
pyperclip==1.8.2
pypiwin32==223
pywin32==303
requests==2.27.1
urllib3==1.26.9
and sure you can try using the below command to show all libraries and their versions
pip list
Hope to Help anyone,
Greetings
In summary:
conda list
(It will provide all the libraries along with version details.)
And:
pip show tensorflow
(It gives complete library details.)
After scouring the Internet, trying to figure out how to ensure the version of a module I’m running (apparently python_is_horrible.__version__ isn’t a thing in Python 2?) across operating systems and Python versions... literally none of these answers worked for my scenario...
Then I thought about it a minute and realized the basics... after ~30 minutes of fails...
assumes the module is already installed and can be imported
Python 3.7
>>> import sys,sqlite3
>>> sys.modules.get("sqlite3").version
'2.6.0'
>>> ".".join(str(x) for x in sys.version_info[:3])
'3.7.2'
Python 2.7
>>> import sys,sqlite3
>>> sys.modules.get("sqlite3").version
'2.6.0'
>>> ".".join(str(x) for x in sys.version_info[:3])
'2.7.11'
Literally that’s it...
(See also How do I get the version of an installed module in Python programmatically?)
I found it quite unreliable to use the various tools available (including the best one pkg_resources mentioned by Jakub Kukul' answer), as most of them do not cover all cases. For example
built-in modules
modules not installed but just added to the python path (by your IDE for example)
two versions of the same module available (one in python path superseding the one installed)
Since we needed a reliable way to get the version of any package, module or submodule, I ended up writing getversion. It is quite simple to use:
from getversion import get_module_version
import foo
version, details = get_module_version(foo)
See the documentation for details.
This works in Jupyter Notebook on Windows, too! As long as Jupyter is launched from a Bash-compliant command line such as Git Bash (Mingw-w64), the solutions given in many of the answers can be used in Jupyter Notebook on Windows systems with one tiny tweak.
I'm running Windows 10 Pro with Python installed via Anaconda, and the following code works when I launch Jupyter via Git Bash (but does not when I launch from the Anaconda prompt).
The tweak: Add an exclamation mark (!) in front of pip to make it !pip.
>>>!pip show lxml | grep Version
Version: 4.1.0
>>>!pip freeze | grep lxml
lxml==4.1.0
>>>!pip list | grep lxml
lxml 4.1.0
>>>!pip show lxml
Name: lxml
Version: 4.1.0
Summary: Powerful and Pythonic XML processing library combining libxml2/libxslt with the ElementTree API.
Home-page: http://lxml.de/
Author: lxml dev team
Author-email: lxml-dev#lxml.de
License: BSD
Location: c:\users\karls\anaconda2\lib\site-packages
Requires:
Required-by: jupyter-contrib-nbextensions
A Python program to list all packages (you can copy it to file requirements.txt):
from pip._internal.utils.misc import get_installed_distributions
print_log = ''
for module in sorted(get_installed_distributions(), key=lambda x: x.key):
print_log += module.key + '~=' + module.version + '\n'
print(print_log)
The output would look like:
asn1crypto~=0.24.0
attrs~=18.2.0
automat~=0.7.0
beautifulsoup4~=4.7.1
botocore~=1.12.98
To get a list of non-standard (pip) modules imported in the current module:
[{pkg.key : pkg.version} for pkg in pip.get_installed_distributions()
if pkg.key in set(sys.modules) & set(globals())]
Result:
>>> import sys, pip, nltk, bs4
>>> [{pkg.key : pkg.version} for pkg in pip.get_installed_distributions() if pkg.key in set(sys.modules) & set(globals())]
[{'pip': '9.0.1'}, {'nltk': '3.2.1'}, {'bs4': '0.0.1'}]
Note:
This code was put together from solutions both on this page and from How to list imported modules?
For situations where field __version__ is not defined:
try:
from importlib import metadata
except ImportError:
import importlib_metadata as metadata # python<=3.7
metadata.version("package")
Alternatively, and like it was already mentioned:
import pkg_resources
pkg_resources.get_distribution('package').version
Here's a small Bash program to get the version of any package in your Python environment. Just copy this to your /usr/bin and provide it with executable permissions:
#!/bin/bash
packageName=$1
python -c "import ${packageName} as package; print(package.__version__)"
Then you can just run it in the terminal, assuming you named the script py-check-version:
py-check-version whatever_package
And in case your production system is hardened beyond comprehension so it has neither pip nor conda, here is a Bash replacement for pip freeze:
ls /usr/local/lib/python3.8/dist-packages | grep info | awk -F "-" '{print $1"=="$2}' | sed 's/.dist//g'
(make sure you update your dist-packages folder to your current python version and ignore inconsistent names, e.g., underscores vs. dashes).
Sample printout:
Flask==1.1.2
Flask_Caching==1.10.1
gunicorn==20.1.0
[..]
I myself work in a heavily restricted server environment and unfortunately none of the solutions here are working for me. There may be no global solution that fits all, but I figured out a swift workaround by reading the terminal output of pip freeze within my script and storing the modules labels and versions in a dictionary.
import os
os.system('pip freeze > tmpoutput')
with open('tmpoutput', 'r') as f:
modules_version = f.read()
module_dict = {item.split("==")[0]:item.split("==")[-1] for item in modules_versions.split("\n")}
Retrieve your module's versions through passing the module label key, e.g.:
>> module_dict["seaborn"]
'0.9.0'
Building on Jakub Kukul's answer I found a more reliable way to solve this problem.
The main problem of that approach is that requires the packages to be installed "conventionally" (and that does not include using pip install --user), or be in the system PATH at Python initialisation.
To get around that you can use pkg_resources.find_distributions(path_to_search). This basically searches for distributions that would be importable if path_to_search was in the system PATH.
We can iterate through this generator like this:
avail_modules = {}
distros = pkg_resources.find_distributions(path_to_search)
for d in distros:
avail_modules[d.key] = d.version
This will return a dictionary having modules as keys and their version as value. This approach can be extended to a lot more than version number.
Thanks to Jakub Kukul for pointing in the right direction.
You can first install some package like this and then check its version:
pip install package
import package
print(package.__version__)
It should give you the package version.
I'm trying to run a script that requires the datasets python package. I've tried installing this unsuccessfully using pip by calling:
pip install datasets
I know this hasn't worked because when I run the script I get the message:
Traceback (most recent call last):
File "lda.py", line 2, in <module>
import lda
File "/Users/deepthought/lda.py", line 3, in <module>
import datasets
ImportError: No module named datasets
I've installed python via homebrew.
When I run pip install datasets I get the error:
Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/ch/84cpkwc52zx0rsh4k5v4_7h40000gn/T/pip-build-gZWyT3/datasets/
I'm fairly new to scripting python or going under the hood of an OS X, so there's a risk I've missed something elementary.
I've been researching & trying to overcome this for about a week now including looking at similar questions on stackoverflow.com and haven't gotten past this stage for the duration. One of the tutorials I was working through told me to edit ~/.profile
This has been left like so:
# The orginal version is saved in .profile.pysave
#PATH="/Library/Frameworks/Python.framework/Versions/3.5/bin:${PATH}"
#export PATH
export PATH=/usr/local/bin:/usr/local/sbin:$PATH
/etc/paths contains:
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
I'm running OS X El Capitan - 10.11.5 (15F34)
Python 2.7.11
Brew doctor flagged multiple items, but I've no idea whether it is worth fixing none/all of them:
Warning: Your XQuartz (2.7.7) is outdated
Please install XQuartz 2.7.9:
https://xquartz.macosforge.org
Warning: Python is installed at /Library/Frameworks/Python.framework
Homebrew only supports building against the System-provided Python or a
brewed Python. In particular, Pythons installed to /Library can interfere
with other software installs.
Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected dylibs:
/usr/local/lib/libtcl8.6.dylib
/usr/local/lib/libtk8.6.dylib
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/fakemysql.h
/usr/local/include/fakepq.h
/usr/local/include/fakesql.h
/usr/local/include/itcl.h
/usr/local/include/itcl2TclOO.h
/usr/local/include/itclDecls.h
/usr/local/include/itclInt.h
/usr/local/include/itclIntDecls.h
/usr/local/include/itclMigrate2TclCore.h
/usr/local/include/itclTclIntStubsFcn.h
/usr/local/include/mysqlStubs.h
/usr/local/include/node/ares.h
/usr/local/include/node/ares_version.h
/usr/local/include/node/nameser.h
/usr/local/include/node/node.h
/usr/local/include/node/node_buffer.h
/usr/local/include/node/node_internals.h
/usr/local/include/node/node_object_wrap.h
/usr/local/include/node/node_version.h
/usr/local/include/node/openssl/opensslconf.h
/usr/local/include/node/uv-private/ngx-queue.h
/usr/local/include/node/uv-private/stdint-msvc2008.h
/usr/local/include/node/uv-private/tree.h
/usr/local/include/node/uv-private/uv-bsd.h
/usr/local/include/node/uv-private/uv-darwin.h
/usr/local/include/node/uv-private/uv-linux.h
/usr/local/include/node/uv-private/uv-sunos.h
/usr/local/include/node/uv-private/uv-unix.h
/usr/local/include/node/uv-private/uv-win.h
/usr/local/include/node/uv.h
/usr/local/include/node/v8-debug.h
/usr/local/include/node/v8-preparser.h
/usr/local/include/node/v8-profiler.h
/usr/local/include/node/v8-testing.h
/usr/local/include/node/v8.h
/usr/local/include/node/v8stdint.h
/usr/local/include/node/zconf.h
/usr/local/include/node/zlib.h
/usr/local/include/odbcStubs.h
/usr/local/include/pqStubs.h
/usr/local/include/tcl.h
/usr/local/include/tclDecls.h
/usr/local/include/tclOO.h
/usr/local/include/tclOODecls.h
/usr/local/include/tclPlatDecls.h
/usr/local/include/tclThread.h
/usr/local/include/tclTomMath.h
/usr/local/include/tclTomMathDecls.h
/usr/local/include/tdbc.h
/usr/local/include/tdbcDecls.h
/usr/local/include/tdbcInt.h
/usr/local/include/tk.h
/usr/local/include/tkDecls.h
/usr/local/include/tkPlatDecls.h
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/tcl.pc
/usr/local/lib/pkgconfig/tk.pc
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libtclstub8.6.a
/usr/local/lib/libtkstub8.6.a
Warning: You have unlinked kegs in your Cellar
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
git
python3
Warning: Broken symlinks were found. Remove them with `brew prune`:
/usr/local/bin/github
/usr/local/lib/perl5/site_perl/Git/I18N.pm
/usr/local/lib/perl5/site_perl/Git/IndexInfo.pm
/usr/local/lib/perl5/site_perl/Git/SVN/Editor.pm
/usr/local/lib/perl5/site_perl/Git/SVN/Fetcher.pm
/usr/local/lib/perl5/site_perl/Git/SVN/GlobSpec.pm
/usr/local/lib/perl5/site_perl/Git/SVN/Log.pm
/usr/local/lib/perl5/site_perl/Git/SVN/Memoize/YAML.pm
/usr/local/lib/perl5/site_perl/Git/SVN/Migration.pm
/usr/local/lib/perl5/site_perl/Git/SVN/Prompt.pm
/usr/local/lib/perl5/site_perl/Git/SVN/Ra.pm
/usr/local/lib/perl5/site_perl/Git/SVN/Utils.pm
/usr/local/lib/perl5/site_perl/Git/SVN.pm
/usr/local/lib/perl5/site_perl/Git.pm
/usr/local/share/git-core/templates/description
/usr/local/share/git-core/templates/hooks/applypatch-msg.sample
/usr/local/share/git-core/templates/hooks/commit-msg.sample
/usr/local/share/git-core/templates/hooks/post-update.sample
/usr/local/share/git-core/templates/hooks/pre-applypatch.sample
/usr/local/share/git-core/templates/hooks/pre-commit.sample
/usr/local/share/git-core/templates/hooks/pre-push.sample
/usr/local/share/git-core/templates/hooks/pre-rebase.sample
/usr/local/share/git-core/templates/hooks/prepare-commit-msg.sample
/usr/local/share/git-core/templates/hooks/update.sample
/usr/local/share/git-core/templates/info/exclude
/usr/local/share/man/man1/git-add.1
/usr/local/share/man/man1/git-am.1
/usr/local/share/man/man1/git-annotate.1
/usr/local/share/man/man1/git-apply.1
/usr/local/share/man/man1/git-archimport.1
/usr/local/share/man/man1/git-archive.1
/usr/local/share/man/man1/git-bisect.1
/usr/local/share/man/man1/git-blame.1
/usr/local/share/man/man1/git-branch.1
/usr/local/share/man/man1/git-bundle.1
/usr/local/share/man/man1/git-cat-file.1
/usr/local/share/man/man1/git-check-attr.1
/usr/local/share/man/man1/git-check-ignore.1
/usr/local/share/man/man1/git-check-mailmap.1
/usr/local/share/man/man1/git-check-ref-format.1
/usr/local/share/man/man1/git-checkout-index.1
/usr/local/share/man/man1/git-checkout.1
/usr/local/share/man/man1/git-cherry-pick.1
/usr/local/share/man/man1/git-cherry.1
/usr/local/share/man/man1/git-citool.1
/usr/local/share/man/man1/git-clean.1
/usr/local/share/man/man1/git-clone.1
/usr/local/share/man/man1/git-column.1
/usr/local/share/man/man1/git-commit-tree.1
/usr/local/share/man/man1/git-commit.1
/usr/local/share/man/man1/git-config.1
/usr/local/share/man/man1/git-count-objects.1
/usr/local/share/man/man1/git-credential-cache--daemon.1
/usr/local/share/man/man1/git-credential-cache.1
/usr/local/share/man/man1/git-credential-store.1
/usr/local/share/man/man1/git-credential.1
/usr/local/share/man/man1/git-cvsexportcommit.1
/usr/local/share/man/man1/git-cvsimport.1
/usr/local/share/man/man1/git-cvsserver.1
/usr/local/share/man/man1/git-daemon.1
/usr/local/share/man/man1/git-describe.1
/usr/local/share/man/man1/git-diff-files.1
/usr/local/share/man/man1/git-diff-index.1
/usr/local/share/man/man1/git-diff-tree.1
/usr/local/share/man/man1/git-diff.1
/usr/local/share/man/man1/git-difftool.1
/usr/local/share/man/man1/git-fast-export.1
/usr/local/share/man/man1/git-fast-import.1
/usr/local/share/man/man1/git-fetch-pack.1
/usr/local/share/man/man1/git-fetch.1
/usr/local/share/man/man1/git-filter-branch.1
/usr/local/share/man/man1/git-fmt-merge-msg.1
/usr/local/share/man/man1/git-for-each-ref.1
/usr/local/share/man/man1/git-format-patch.1
/usr/local/share/man/man1/git-fsck-objects.1
/usr/local/share/man/man1/git-fsck.1
/usr/local/share/man/man1/git-gc.1
/usr/local/share/man/man1/git-get-tar-commit-id.1
/usr/local/share/man/man1/git-grep.1
/usr/local/share/man/man1/git-gui.1
/usr/local/share/man/man1/git-hash-object.1
/usr/local/share/man/man1/git-help.1
/usr/local/share/man/man1/git-http-backend.1
/usr/local/share/man/man1/git-http-fetch.1
/usr/local/share/man/man1/git-http-push.1
/usr/local/share/man/man1/git-imap-send.1
/usr/local/share/man/man1/git-index-pack.1
/usr/local/share/man/man1/git-init-db.1
/usr/local/share/man/man1/git-init.1
/usr/local/share/man/man1/git-instaweb.1
/usr/local/share/man/man1/git-log.1
/usr/local/share/man/man1/git-lost-found.1
/usr/local/share/man/man1/git-ls-files.1
/usr/local/share/man/man1/git-ls-remote.1
/usr/local/share/man/man1/git-ls-tree.1
/usr/local/share/man/man1/git-mailinfo.1
/usr/local/share/man/man1/git-mailsplit.1
/usr/local/share/man/man1/git-merge-base.1
/usr/local/share/man/man1/git-merge-file.1
/usr/local/share/man/man1/git-merge-index.1
/usr/local/share/man/man1/git-merge-one-file.1
/usr/local/share/man/man1/git-merge-tree.1
/usr/local/share/man/man1/git-merge.1
/usr/local/share/man/man1/git-mergetool--lib.1
/usr/local/share/man/man1/git-mergetool.1
/usr/local/share/man/man1/git-mktag.1
/usr/local/share/man/man1/git-mktree.1
/usr/local/share/man/man1/git-mv.1
/usr/local/share/man/man1/git-name-rev.1
/usr/local/share/man/man1/git-notes.1
/usr/local/share/man/man1/git-p4.1
/usr/local/share/man/man1/git-pack-objects.1
/usr/local/share/man/man1/git-pack-redundant.1
/usr/local/share/man/man1/git-pack-refs.1
/usr/local/share/man/man1/git-parse-remote.1
/usr/local/share/man/man1/git-patch-id.1
/usr/local/share/man/man1/git-peek-remote.1
/usr/local/share/man/man1/git-prune-packed.1
/usr/local/share/man/man1/git-prune.1
/usr/local/share/man/man1/git-pull.1
/usr/local/share/man/man1/git-push.1
/usr/local/share/man/man1/git-quiltimport.1
/usr/local/share/man/man1/git-read-tree.1
/usr/local/share/man/man1/git-rebase.1
/usr/local/share/man/man1/git-receive-pack.1
/usr/local/share/man/man1/git-reflog.1
/usr/local/share/man/man1/git-relink.1
/usr/local/share/man/man1/git-remote-ext.1
/usr/local/share/man/man1/git-remote-fd.1
/usr/local/share/man/man1/git-remote-testgit.1
/usr/local/share/man/man1/git-remote.1
/usr/local/share/man/man1/git-repack.1
/usr/local/share/man/man1/git-replace.1
/usr/local/share/man/man1/git-repo-config.1
/usr/local/share/man/man1/git-request-pull.1
/usr/local/share/man/man1/git-rerere.1
/usr/local/share/man/man1/git-reset.1
/usr/local/share/man/man1/git-rev-list.1
/usr/local/share/man/man1/git-rev-parse.1
/usr/local/share/man/man1/git-revert.1
/usr/local/share/man/man1/git-rm.1
/usr/local/share/man/man1/git-send-email.1
/usr/local/share/man/man1/git-send-pack.1
/usr/local/share/man/man1/git-sh-i18n--envsubst.1
/usr/local/share/man/man1/git-sh-i18n.1
/usr/local/share/man/man1/git-sh-setup.1
/usr/local/share/man/man1/git-shell.1
/usr/local/share/man/man1/git-shortlog.1
/usr/local/share/man/man1/git-show-branch.1
/usr/local/share/man/man1/git-show-index.1
/usr/local/share/man/man1/git-show-ref.1
/usr/local/share/man/man1/git-show.1
/usr/local/share/man/man1/git-stage.1
/usr/local/share/man/man1/git-stash.1
/usr/local/share/man/man1/git-status.1
/usr/local/share/man/man1/git-stripspace.1
/usr/local/share/man/man1/git-submodule.1
/usr/local/share/man/man1/git-svn.1
/usr/local/share/man/man1/git-symbolic-ref.1
/usr/local/share/man/man1/git-tag.1
/usr/local/share/man/man1/git-tar-tree.1
/usr/local/share/man/man1/git-unpack-file.1
/usr/local/share/man/man1/git-unpack-objects.1
/usr/local/share/man/man1/git-update-index.1
/usr/local/share/man/man1/git-update-ref.1
/usr/local/share/man/man1/git-update-server-info.1
/usr/local/share/man/man1/git-upload-archive.1
/usr/local/share/man/man1/git-upload-pack.1
/usr/local/share/man/man1/git-var.1
/usr/local/share/man/man1/git-verify-pack.1
/usr/local/share/man/man1/git-verify-tag.1
/usr/local/share/man/man1/git-web--browse.1
/usr/local/share/man/man1/git-whatchanged.1
/usr/local/share/man/man1/git-write-tree.1
/usr/local/share/man/man1/git.1
/usr/local/share/man/man1/gitk.1
/usr/local/share/man/man1/gitremote-helpers.1
/usr/local/share/man/man1/gitweb.1
/usr/local/share/man/man3/Git.3pm
/usr/local/share/man/man3/Git::I18N.3pm
/usr/local/share/man/man3/Git::SVN::Editor.3pm
/usr/local/share/man/man3/Git::SVN::Fetcher.3pm
/usr/local/share/man/man3/Git::SVN::Memoize::YAML.3pm
/usr/local/share/man/man3/Git::SVN::Prompt.3pm
/usr/local/share/man/man3/Git::SVN::Ra.3pm
/usr/local/share/man/man3/Git::SVN::Utils.3pm
/usr/local/share/man/man5/gitattributes.5
/usr/local/share/man/man5/githooks.5
/usr/local/share/man/man5/gitignore.5
/usr/local/share/man/man5/gitmodules.5
/usr/local/share/man/man5/gitrepository-layout.5
/usr/local/share/man/man5/gitweb.conf.5
/usr/local/share/man/man7/gitcli.7
/usr/local/share/man/man7/gitcore-tutorial.7
/usr/local/share/man/man7/gitcredentials.7
/usr/local/share/man/man7/gitcvs-migration.7
/usr/local/share/man/man7/gitdiffcore.7
/usr/local/share/man/man7/gitglossary.7
/usr/local/share/man/man7/gitnamespaces.7
/usr/local/share/man/man7/gitrevisions.7
/usr/local/share/man/man7/gittutorial-2.7
/usr/local/share/man/man7/gittutorial.7
/usr/local/share/man/man7/gitworkflows.7
Warning: Your Homebrew is outdated.
You haven't updated for at least 24 hours. This is a long time in brewland!
To update Homebrew, run `brew update`.
How do I make progress in diagnosing the issue with the installation of the datasets package?
Update
Here is the script I'm trying to run:
import sys
egg_path = '/usr/local/lib/python2.7/site-packages/datasets-0.0.9-py2.7.egg'
sys.path.append(egg_path)
import numpy as np
import lda
import datasets
X = lda.datasets.load_reuters()
vocab = lda.datasets.load_reuters_vocab()
titles = lda.datasets.load_reuters_titles()
X.shape
(395, 4258)
X.sum()
84010
model = lda.LDA(n_topics=20, n_iter=1500, random_state=1)
model.fit(X) # model.fit_transform(X) is also available
topic_word = model.topic_word_ # model.components_ also works
n_top_words = 8
for i, topic_dist in enumerate(topic_word):
topic_words = np.array(vocab)[np.argsort(topic_dist)][:-(n_top_words+1):-1]
print('Topic {}: {}'.format(i, ' '.join(topic_words)))
Using pip install datasets I was also not able to properly install this package. It seems like there is a bug in this particular package.
The DESCRIBE.rst file is simply missing. To fix this just download the plain package from PyPi. https://pypi.python.org/pypi/datasets/0.0.9
Then adjust the setup.py file (remove the description).
Afterwards you need to install using python setup.py install. Don't forget to add the installed package to your Python path!
To do so, I would recommend that you add the following to your script.
import sys
egg_path = '__MODULE_PATH__/datasets-0.0.9-py3.5.egg'
sys.path.append(egg_path)
import datasets
Otherwise, you can also add your module using:
export PATH=__MODULE_PATH__:$PATH
Alternatively, you could also simply pull the source code from the Github repository and just include it in your project. https://github.com/realtimeweb/datasets
Hope this was kind of helpful to your problem. If you got any further questions just let me know.
I just hit the same issue on a rapsberry pi, just found out this had been fixed but the error comes from the lack of ram to extract properly the package.
You can fix this by disabling the creation of a cache dir in ram adding the parameter
--no-cache-dir
for example
pip2 install --user --no-cache-dir datasets
I'm developing my own module in python 2.7. It resides in ~/Development/.../myModule instead of /usr/lib/python2.7/dist-packages or /usr/lib/python2.7/site-packages. The internal structure is:
/project-root-dir
/server
__init__.py
service.py
http.py
/client
__init__.py
client.py
client/client.py includes PyCachedClient class. I'm having import problems:
project-root-dir$ python
Python 2.7.2+ (default, Jul 20 2012, 22:12:53)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from server import http
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "server/http.py", line 9, in <module>
from client import PyCachedClient
ImportError: cannot import name PyCachedClient
I didn't set PythonPath to include my project-root-dir, therefore when server.http tries to include client.PyCachedClient, it tries to load it from relative path and fails. My question is - how should I set all paths/settings in a good, pythonic way? I know I can run export PYTHONPATH=... in shell each time I open a console and try to run my server, but I guess it's not the best way. If my module was installed via PyPi (or something similar), I'd have it installed in /usr/lib/python... path and it'd be loaded automatically.
I'd appreciate tips on best practices in python module development.
My Python development workflow
This is a basic process to develop Python packages that incorporates what I believe to be the best practices in the community. It's basic - if you're really serious about developing Python packages, there still a bit more to it, and everyone has their own preferences, but it should serve as a template to get started and then learn more about the pieces involved. The basic steps are:
Use virtualenv for isolation
setuptools for creating a installable package and manage dependencies
python setup.py develop to install that package in development mode
virtualenv
First, I would recommend using virtualenv to get an isolated environment to develop your package(s) in. During development, you will need to install, upgrade, downgrade and uninstall dependencies of your package, and you don't want
your development dependencies to pollute your system-wide site-packages
your system-wide site-packages to influence your development environment
version conflicts
Polluting your system-wide site-packages is bad, because any package you install there will be available to all Python applications you installed that use the system Python, even though you just needed that dependency for your small project. And it was just installed in a new version that overrode the one in the system wide site-packages, and is incompatible with ${important_app} that depends on it. You get the idea.
Having your system wide site-packages influence your development environment is bad, because maybe your project depends on a module you already got in the system Python's site-packages. So you forget to properly declare that your project depends on that module, but everything works because it's always there on your local development box. Until you release your package and people try to install it, or push it to production, etc... Developing in a clean environment forces you to properly declare your dependencies.
So, a virtualenv is an isolated environment with its own Python interpreter and module search path. It's based on a Python installation you previously installed, but isolated from it.
To create a virtualenv, install the virtualenv package by installing it to your system wide Python using easy_install or pip:
sudo pip install virtualenv
Notice this will be the only time you install something as root (using sudo), into your global site-packages. Everything after this will happen inside the virtualenv you're about to create.
Now create a virtualenv for developing your package:
cd ~/pyprojects
virtualenv --no-site-packages foobar-env
This will create a directory tree ~/pyprojects/foobar-env, which is your virtualenv.
To activate the virtualenv, cd into it and source the bin/activate script:
~/pyprojects $ cd foobar-env/
~/pyprojects/foobar-env $ . bin/activate
(foobar-env) ~/pyprojects/foobar-env $
Note the leading dot ., that's shorthand for the source shell command. Also note how the prompt changes: (foobar-env) means your inside the activated virtualenv (and always will need to be for the isolation to work). So activate your env every time you open a new terminal tab or SSH session etc..
If you now run python in that activated env, it will actually use ~/pyprojects/foobar-env/bin/python as the interpreter, with its own site-packages and isolated module search path.
A setuptools package
Now for creating your package. Basically you'll want a setuptools package with a setup.py to properly declare your package's metadata and dependencies. You can do this on your own by by following the setuptools documentation, or create a package skeletion using Paster templates. To use Paster templates, install PasteScript into your virtualenv:
pip install PasteScript
Let's create a source directory for our new package to keep things organized (maybe you'll want to split up your project into several packages, or later use dependencies from source):
mkdir src
cd src/
Now for creating your package, do
paster create -t basic_package foobar
and answer all the questions in the interactive interface. Most are optional and can simply be left at the default by pressing ENTER.
This will create a package (or more precisely, a setuptools distribution) called foobar. This is the name that
people will use to install your package using easy_install or pip install foobar
the name other packages will use to depend on yours in setup.py
what it will be called on PyPi
Inside, you almost always create a Python package (as in "a directory with an __init__.py) that's called the same. That's not required, the name of the top level Python package can be any valid package name, but it's a common convention to name it the same as the distribution. And that's why it's important, but not always easy, to keep the two apart. Because the top level python package name is what
people (or you) will use to import your package using import foobar or from foobar import baz
So if you used the paster template, it will already have created that directory for you:
cd foobar/foobar/
Now create your code:
vim models.py
models.py
class Page(object):
"""A dumb object wrapping a webpage.
"""
def __init__(self, content, url):
self.content = content
self.original_url = url
def __repr__(self):
return "<Page retrieved from '%s' (%s bytes)>" % (self.original_url, len(self.content))
And a client.py in the same directory that uses models.py:
client.py
import requests
from foobar.models import Page
url = 'http://www.stackoverflow.com'
response = requests.get(url)
page = Page(response.content, url)
print page
Declare the dependency on the requests module in setup.py:
install_requires=[
# -*- Extra requirements: -*-
'setuptools',
'requests',
],
Version control
src/foobar/ is the directory you'll now want to put under version control:
cd src/foobar/
git init
vim .gitignore
.gitignore
*.egg-info
*.py[co]
git add .
git commit -m 'Create initial package structure.
Installing your package as a development egg
Now it's time to install your package in development mode:
python setup.py develop
This will install the requests dependency and your package as a development egg. So it's linked into your virtualenv's site-packages, but still lives at src/foobar where you can make changes and have them be immediately active in the virtualenv without re-installing your package.
Now for your original question, importing using relative paths: My advice is, don't do it. Now that you've got a proper setuptools package, that's installed and importable, your current working directory shouldn't matter any more. Just do from foobar.models import Page or similar, declaring the fully qualified name where that object lives. That makes your source code much more readable and discoverable, for yourself and other people that read your code.
You can now run your code by doing python client.py from anywhere inside your activated virtualenv. python src/foobar/foobar/client.py works just as fine, your package is properly installed and your working directory doesn't matter any more.
If you want to go one step further, you can even create a setuptools entry point for your CLI scripts. This will create a bin/something script in your virtualenv that you can run from the shell.
setuptools console_scripts entry point
setup.py
entry_points='''
# -*- Entry points: -*-
[console_scripts]
run-fooobar = foobar.main:run_foobar
''',
client.py
def run_client():
# ...
main.py
from foobar.client import run_client
def run_foobar():
run_client()
Re-install your package to activate the entry point:
python setup.py develop
And there you go, bin/run-foo.
Once you (or someone else) installs your package for real, outside the virtualenv, the entry point will be in /usr/local/bin/run-foo or somewhere simiar, where it will automatically be in $PATH.
Further steps
Creating a release of your package and uploading it PyPi, for example using zest.releaser
Keeping a changelog and versioning your package
Learn about declaring dependencies
Learn about Differences between distribute, distutils, setuptools and distutils2
Suggested reading:
The Hitchhiker’s Guide to Packaging
The pip cookbook
So, you have two packages, the first with modules named:
server # server/__init__.py
server.service # server/service.py
server.http # server/http.py
The second with modules names:
client # client/__init__.py
client.client # client/client.py
If you want to assume both packages are in you import path (sys.path), and the class you want is in client/client.py, then in you server you have to do:
from client.client import PyCachedClient
You asked for a symbol out of client, not client.client, and from your description, that isn't where that symbol is defined.
I personally would consider making this one package (ie, putting an __init__.py in the folder one level up, and giving it a suitable python package name), and having client and server be sub-packages of that package. Then (a) you could do relative imports if you wanted to (from ...client.client import something), and (b) your project would be more suitable for redistribution, not putting two very generic package names at the top level of the python module hierarchy.
I am trying to use google protocol buffer in windows with python binding, however I meet some problem during the install step.
Follow the instruction, I have to compile the PB myself using vs, but I have no vs installed on my machine, then I found a window binary at the download page.
Also I download the full source code package, then I put the protoc-2.5.0-win32.zip\protoc.exe to C:\windows\system32.
Then I go to the protobuf-2.5.0.zip\python and run the python setup.py install to install the python binding.
However I get the error like this:
And when I check the directory, the file google\protobuf\compiler does not exist.
What's the problem?
Is it possible to use it without compiling?
I was just suffering from the same problem. The solution is to explicitly do the build step before.
python setup.py build
python setup.py install
That worked for me.
Before this package can be installed on windows you need to download the compiler (protoc.exe) and put it in the environment execution path.
After this step is done you can run:
python setup.py build
python setup.py install
~yy
C:\Users\dev3\protobufcode\protobuf-master\python
$ python setup.py build
$ python setup.py install
C:\Users\dev3\protobufcode
$ python --version
Python 3.6.5
$ python -i build\gen\addressbook_pb2.py
>>> import addressbook_pb2
>>> Person = addressbook_pb2.Person()
>>> person = addressbook_pb2.Person()
>>> person.id = 1234
>>> person.name = "Go Fish"
>>> person.email = "gofish#example.com"
>>> phone = person.phones.add()
>>> phone.number = "111-2222"
>>> phone.type = addressbook_pb2.Person.HOME
>>> person
name: "Go Fish"
id: 1234
email: "gofish#example.com"
phones {
number: "111-2222"
type: HOME
}
>>>