Ubuntu Linux has a package named "python-wstools" that installed a number of files including two .gz files. the package in PyPI of the same name does not have any .gz files so i must conclude Ubuntu packagers added them. they a both in the "tests" subdirectory which the PyPI package did not have. so i am inclined to blame Ubuntu for them being corrupt.
here's what i wonder. these are in a python-2.7 directory, only. does this even matter now that Python2 is well past EoL?
Output:
ModuleNotFoundError: No module named 'wstools'
i guess not.
Do it the normally way with Python i never use Distors internal packages(often not updated) for Python.
Quick test.
tom@tom-VirtualBox:~$ python -m venv ws_env
tom@tom-VirtualBox:~$ cd ws_env
tom@tom-VirtualBox:~/ws_env$ source bin/activate
(ws_env) tom@tom-VirtualBox:~/ws_env$ pip install wstools
Collecting wstools .....
Successfully installed pbr-5.6.0 six-1.16.0 wstools-0.4.8
(ws_env) tom@tom-VirtualBox:~/ws_env$ python
Python 3.9.1 (default, Jan 25 2021, 15:34:59)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import wstools
>>>
>>> wstools.__version__
'0.4.8'
>>> exit()
(ws_env) tom@tom-VirtualBox:~/ws_env$ pip list
Package Version
---------- -------
pbr 5.6.0
pip 21.1.3
setuptools 49.2.1
six 1.16.0
wstools 0.4.8
In many versions of Ubuntu, packages for python 3 start with the prefix python3- . For example I see a package python3-wstool in my Ubuntu packages (note that there is no final 's'). That said, it is true that distro's python modules are often outdated. I often manage them with pip and the --user switch, for example
Output:
pip install --user -U wstools
if i was seriously going to use the package, i'd install it with pip, too. this is probably a good example why. i think it was a leftover from playing around (not serious usage) in an earlier Ubuntu.
i discovered these files while testing a script (
zhash.py) that does a hash of the uncompressed form of files in a tree. it used my not-yet-released module named
zopen that compresses or uncompresses files based on the file name extension(s). it also uses my
ftrgen module to flatten the file tree. i wanted to give something big to do some long timing so i ran it for
/usr. when writing a file,
zopen() can write to a temporary file name and move the temporary name to the target name given when it is closed.
compressing_file = zopen('foo.gz.bz2.xz','w',tempname=True)if the file name has multiple compression extensions (sometimes useful) it handles them. one hazard i ran into was a file with a few hundred trillion binary zeros that double compressed very small. it had no idea that this would take most of a day to uncompress. compressing it took a whole weekend.