Re: I'm finally disentangled from Python 2, thank you everyone
> Could I ask you to write up a post on what you did here? I've never used > cx-freeze but it sounds like a useful thing for keeping legacy stuff > functioning. A writeup from someone who's actually used it for that > would be welcome. > Of course, here is what I wrote in my 'self help' Dokuwiki wiki about it. It refers specifically to the OKI software I wanted to keep using but it should be fairly easy to apply a similar process to other software. I asked on the Python newsgroup and the one suggestion that seemed feasible was to package the OKI software with all its dependencies on a system which still has Gtk2 and Python 2 and then install the whole package on esprimo. After a bit of looking around at Snap, Appimage and such I found cx_freeze which is aimed specifically at Python. The latest version doesn't support Python 2 but 5.1.1 does, so this is how I've have done it * Install xubuntu 18.04 on my old Revo system (has to be 64-bit), 18.04 is still in support. (has to be 64-bit simply because the final target is 64-bit) * Install cx_freeze 5.1.1 on Revo * Install the Oki software on Revo, check that it works, pulls in lots of libraries and packages. * Run 'cxfreeze /usr/libexec/okimfputl/scantool.py' (scantool.py is the utility I want to run on systems without Python 2) * Copy the resulting 'dist' directory to the target system, name isn't critical Then the fun starts. There's quite a few more libraries and packages are required and the scan daemon needs to be runnable. (The scan daemon was, fortunately, just a compiled program so ran 'as is' without issues) Files needed in /usr/libexec/okimfputl and /usr/libexec/okimfpdrv " There are a lot of hard coded references to /usr/libexec/okimfputl and /usr/libexec/okimfpdrv, it **might** be possible to change all these but I decided it would be less painful to use a couple of symbolic links to locations in /usr/local/libexec and put the required files in /usr/local/libexec/okimfputl and /usr/local/libexec/okimfpdrv. I discovered what files are needed in these directories by simply running scantool on the target and fixing each error as it arose. Other Python package and library files " I have installed the "dist" created by cxfreeze in /usr/local/libexec/okicxfreeze. The executable to run is thus /usr/local/libexec/okicxfreeze/scantool. There are also a few .so libraries and Python packages needed, as above I just found these by running scantool and fixing each error as it appeared. The system library files are put in /usr/local/lib, you have to run ldconfig after each file is put there. The Python packages (including the dreaded pyscand.so) have to be put in the working directory when scantool is run, so I have put them in /usr/local/libexec/okicxfreeze where the scantool executable is. I hope the above is useful. As I said it refers specifically to the scantool.py that I needed for my Oki scanner but I think the description is general enough to be useful. The basic process is:- Find (or create) a system where the software you want to run works OK. Install cx-freeze 5.1.1 on that system and run 'cxfreeze ' Check that the executable created by cxfreeze works on the system you built it on Copy the executable (and its 'dist' environment) to the target where you want to run it Try and run it on the target Iteratively work through the errors it throws up when you run it, in my case these were:- Missing .so system library files, copy them from the build system to somewhere they will be found on the target. You could put them in a 'private to the package' directory and set LD_LIBRARY_PATH or do as I did and put them in a standard library location (and run ldconfig after adding each). Missing Python packages, in my case this included the dreaded pyscand.so, I just put them in the 'package' directory with the executable and in the script that calls the executable set the directory so they are found. Data files. In my case these had locations which were hard coded into all the various scripts along with scantool.py. I *could* have changed all the code before building but that would have been a bit messy and error prone and there was no guarantee that there weren't some addresses hard coded in the executable files and libraries so I just (as you can see above) set up the required directories and put the required files there. In my case this was just three or four configuration files and four .png image files. Note: It seems that what cxfreeze does is to create the *Python* environment needed to run a program. It assumes t
Re: Why do I have both /usr/lib/python3 and /usr/lib/python3.8?
Chris Green writes: > Why are there both /usr/lib/python3 and /usr/lib/python3.8 on my > x[ubuntu] system? While it's more of an Ubuntu (or Debian) question better asked in some relevant Linux forum, in the end it's because some package managers decided to do that. You can use commands like these to see which packages put stuff in which directory: dpkg -S /usr/lib/python3.8 dpkg -S /usr/lib/python3 On my Debian system the corresponding output looks like this: $ dpkg -S /usr/lib/python3.7 python3.7, libpython3.7-minimal:amd64, python3-tk:amd64, libpython3.7-dev:amd64, libpython3.7-stdlib:amd64, libpython3.7:amd64, python3-distutils, python3-lib2to3: /usr/lib/python3.7 $ dpkg -S /usr/lib/python3 python3-scipy, python3-opengl, python3-statsmodels, iotop, python3-reportlab-accel:amd64, python3-magic, python3-pkg-resources, python3-kiwisolver, python3.7, python3-pandas-lib, python3-kerberos, python3-lz4, python3-renderpm:amd64, python3-numexpr, python3-cffi-backend, python3-crypto, python3-tables, python3-rencode, python3-gi, python3-dbus, devscripts, python3-gpg, python3-pyasn1, python3-py, python3-eyed3, pdfarranger, python3-pip, python3-virtualenv, xpra, python3-pandas, python3-pil:amd64, python3-requests, python3-urllib3, python3-psutil, python3-paramiko, python3-netifaces, python3-patsy, python3-gssapi, python3-sklearn, python3-cycler, python3-sip, python3-cairo:amd64, python3-six, python3-chardet, python3-nose, python3-debian, python3-wheel, python3-attr, python3-soupsieve, python3-bcrypt, python3-bs4, python3-sklearn-lib, python3-scour, python3-setuptools, python3-entrypoints, python3-gi-cairo, python3-cups, python3-keyrings.alt, python3-pluggy, python3-tz, python3-ifaddr, python3-joblib, python3-cvxopt, python3-secretstorage, python3-reportlab, python3-more-itertools, python3-keyring, python3-asn1crypto, python3-html5lib, python3-dns, python3-decorator, python3-dateutil, meson, python3-pexpect, python3-idna, python3-seaborn, lsb-release, python3-numpy, python3-brotli, python3-tables-lib, python3-lxml:amd64, python3-pytest, python3-simplejson, python3-nacl, python3-zeroconf, python3-xdg, python3-libvoikko, python3-gst-1.0, python3-pypdf2, python3-evdev, python3-matplotlib, python3-statsmodels-lib, python3-cryptography, python3-certifi, python3-atomicwrites, python3-pyparsing, python3-ptyprocess, python3-webencodings, piper, python3-uno, python3-apt, python3-setproctitle:amd64, hplip: /usr/lib/python3 So I'd say as a rule stuff relevant to the specific version of python goes in the specific version directory (i.e. /usr/lib/python3.8 in your case) and python software packages in general go in /usr/lib/python3. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why do I have both /usr/lib/python3 and /usr/lib/python3.8?
Anssi Saari wrote: > Chris Green writes: > > > Why are there both /usr/lib/python3 and /usr/lib/python3.8 on my > > x[ubuntu] system? > > While it's more of an Ubuntu (or Debian) question better asked in some > relevant Linux forum, in the end it's because some package managers > decided to do that. You can use commands like these to see which > packages put stuff in which directory: > > dpkg -S /usr/lib/python3.8 > dpkg -S /usr/lib/python3 > > On my Debian system the corresponding output looks like this: > > $ dpkg -S /usr/lib/python3.7 > python3.7, libpython3.7-minimal:amd64, python3-tk:amd64, > libpython3.7-dev:amd64, libpython3.7-stdlib:amd64, libpython3.7:amd64, > python3-distutils, python3-lib2to3: /usr/lib/python3.7 > > $ dpkg -S /usr/lib/python3 > python3-scipy, python3-opengl, python3-statsmodels, iotop, > python3-reportlab-accel:amd64, python3-magic, python3-pkg-resources, > python3-kiwisolver, python3.7, python3-pandas-lib, python3-kerberos, > python3-lz4, python3-renderpm:amd64, python3-numexpr, > python3-cffi-backend, python3-crypto, python3-tables, python3-rencode, > python3-gi, python3-dbus, devscripts, python3-gpg, python3-pyasn1, > python3-py, python3-eyed3, pdfarranger, python3-pip, python3-virtualenv, > xpra, python3-pandas, python3-pil:amd64, python3-requests, > python3-urllib3, python3-psutil, python3-paramiko, python3-netifaces, > python3-patsy, python3-gssapi, python3-sklearn, python3-cycler, > python3-sip, python3-cairo:amd64, python3-six, python3-chardet, > python3-nose, python3-debian, python3-wheel, python3-attr, > python3-soupsieve, python3-bcrypt, python3-bs4, python3-sklearn-lib, > python3-scour, python3-setuptools, python3-entrypoints, > python3-gi-cairo, python3-cups, python3-keyrings.alt, python3-pluggy, > python3-tz, python3-ifaddr, python3-joblib, python3-cvxopt, > python3-secretstorage, python3-reportlab, python3-more-itertools, > python3-keyring, python3-asn1crypto, python3-html5lib, python3-dns, > python3-decorator, python3-dateutil, meson, python3-pexpect, > python3-idna, python3-seaborn, lsb-release, python3-numpy, > python3-brotli, python3-tables-lib, python3-lxml:amd64, python3-pytest, > python3-simplejson, python3-nacl, python3-zeroconf, python3-xdg, > python3-libvoikko, python3-gst-1.0, python3-pypdf2, python3-evdev, > python3-matplotlib, python3-statsmodels-lib, python3-cryptography, > python3-certifi, python3-atomicwrites, python3-pyparsing, > python3-ptyprocess, python3-webencodings, piper, python3-uno, > python3-apt, python3-setproctitle:amd64, hplip: /usr/lib/python3 > > So I'd say as a rule stuff relevant to the specific version of python > goes in the specific version directory (i.e. /usr/lib/python3.8 in your > case) and python software packages in general go in /usr/lib/python3. > Yes, there are some oddities though, for example python3.7 seems to be installed in both locations (python3.8 in my case). -- Chris Green ยท -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm finally disentangled from Python 2, thank you everyone
Am 30.12.20 um 11:58 schrieb Chris Green: Could I ask you to write up a post on what you did here? I've never used cx-freeze but it sounds like a useful thing for keeping legacy stuff functioning. A writeup from someone who's actually used it for that would be welcome. Of course, here is what I wrote in my 'self help' Dokuwiki wiki about it. It refers specifically to the OKI software I wanted to keep using but it should be fairly easy to apply a similar process to other software. I asked on the Python newsgroup and the one suggestion that seemed feasible was to package the OKI software with all its dependencies on a system which still has Gtk2 and Python 2 and then install the whole package on esprimo. After a bit of looking around at Snap, Appimage and such I found cx_freeze which is aimed specifically at Python. The latest version doesn't support Python 2 but 5.1.1 does, so this is how I've have done it * Install xubuntu 18.04 on my old Revo system (has to be 64-bit), 18.04 is still in support. (has to be 64-bit simply because the final target is 64-bit) * Install cx_freeze 5.1.1 on Revo * Install the Oki software on Revo, check that it works, pulls in lots of libraries and packages. * Run 'cxfreeze /usr/libexec/okimfputl/scantool.py' (scantool.py is the utility I want to run on systems without Python 2) * Copy the resulting 'dist' directory to the target system, name isn't critical Then the fun starts. There's quite a few more libraries and packages are required and the scan daemon needs to be runnable. (The scan daemon was, fortunately, just a compiled program so ran 'as is' without issues) Files needed in /usr/libexec/okimfputl and /usr/libexec/okimfpdrv " There are a lot of hard coded references to /usr/libexec/okimfputl and /usr/libexec/okimfpdrv, it **might** be possible to change all these but I decided it would be less painful to use a couple of symbolic links to locations in /usr/local/libexec and put the required files in /usr/local/libexec/okimfputl and /usr/local/libexec/okimfpdrv. I discovered what files are needed in these directories by simply running scantool on the target and fixing each error as it arose. Other Python package and library files " I have installed the "dist" created by cxfreeze in /usr/local/libexec/okicxfreeze. The executable to run is thus /usr/local/libexec/okicxfreeze/scantool. There are also a few .so libraries and Python packages needed, as above I just found these by running scantool and fixing each error as it appeared. The system library files are put in /usr/local/lib, you have to run ldconfig after each file is put there. The Python packages (including the dreaded pyscand.so) have to be put in the working directory when scantool is run, so I have put them in /usr/local/libexec/okicxfreeze where the scantool executable is. I hope the above is useful. As I said it refers specifically to the scantool.py that I needed for my Oki scanner but I think the description is general enough to be useful. The basic process is:- Find (or create) a system where the software you want to run works OK. Install cx-freeze 5.1.1 on that system and run 'cxfreeze ' Check that the executable created by cxfreeze works on the system you built it on Copy the executable (and its 'dist' environment) to the target where you want to run it Try and run it on the target Iteratively work through the errors it throws up when you run it, in my case these were:- Missing .so system library files, copy them from the build system to somewhere they will be found on the target. You could put them in a 'private to the package' directory and set LD_LIBRARY_PATH or do as I did and put them in a standard library location (and run ldconfig after adding each). I've used pyinstaller in the past, and it seems to do a better job with that. It usually copies all the sytem libraries, too, but would fail with /usr/libexec/okimfputl & friends Christian -- https://mail.python.org/mailman/listinfo/python-list
bCNC
I have installed Python 3.9.0 and 3.9.1 in an effort to install bCNC.
After entering the cmd prompt for installing bCNC the reply indicates
intsall was successful.
However when trying to launch bCNC with command prompt I get the following
reply.
Microsoft Windows [Version 10.0.19041.685]
(c) 2020 Microsoft Corporation. All rights reserved.
C:\Users\->py -m bCNC
new-config Utils
** On entry to DGEBAL parameter number 3 had an illegal value
** On entry to DGEHRD parameter number 2 had an illegal value
** On entry to DORGHR DORGQR parameter number 2 had an illegal value
** On entry to DHSEQR parameter number 4 had an illegal value
Traceback (most recent call last):
File
"C:\Users\\AppData\Local\Programs\Python\Python39\lib\runpy.py",
line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File
"C:\Users\-\AppData\Local\Programs\Python\Python39\lib\runpy.py",
line 87, in _run_code
exec(code, run_globals)
File
"C:\Users\--\AppData\Local\Programs\Python\Python39\lib\site-packages\bCNC\__main__.py",
line 60, in
from CNC import WAIT, CNC, GCode
File
"C:\Users\---\AppData\Local\Programs\Python\Python39\lib\site-packages\bCNC\CNC.py",
line 25, in
from svgcodeimport SVGcode
File
"C:\Users\-\AppData\Local\Programs\Python\Python39\lib\site-packages\bCNC\lib\svgcode.py",
line 13, in
import numpy
File
"C:\Users\-\AppData\Local\Programs\Python\Python39\lib\site-packages\numpy\__init__.py",
line 305, in
_win_os_check()
File
"C:\Users\---\AppData\Local\Programs\Python\Python39\lib\site-packages\numpy\__init__.py",
line 302, in _win_os_check
raise RuntimeError(msg.format(__file__)) from None
RuntimeError: The current Numpy installation
('C:\\Users\\--\\AppData\\Local\\Programs\\Python\\Python39\\lib\\site-packages\\numpy\\__init__.py')
fails to pass a sanity check due to a bug in the windows runtime. See this
issue for more information: https://tinyurl.com/y3dm3h86
C:\Users\-->
Any help would be greatly appreciated.
--
Thanks
Mark Bachman
People love chopping wood. In this activity one immediately sees results.
Albert Einstein
--
https://mail.python.org/mailman/listinfo/python-list
ipython missing required module with python-3.9.1
Using the installed Python3-3.9.1 I rebuilt all python3 modules, including python3-prompt_toolkit-3.0.8, python3-ipython-7.19.0, and ipython_genutils. Trying to invoke ipython results in a not-found module: $ ipython Traceback (most recent call last): File "/usr/bin/ipython", line 4, in from IPython import start_ipython File "/usr/lib64/python3.9/site-packages/IPython/__init__.py", line 56, in from .terminal.embed import embed File "/usr/lib64/python3.9/site-packages/IPython/terminal/embed.py", line 16, in from IPython.terminal.interactiveshell import TerminalInteractiveShell File "/usr/lib64/python3.9/site-packages/IPython/terminal/interactiveshell.py", line 21, in from prompt_toolkit.formatted_text import PygmentsTokens ModuleNotFoundError: No module named 'prompt_toolkit.formatted_text' Running python3 from the command line I see there is no formatted_text in prompt_toolkit: dir(prompt_toolkit) ['AbortAction', 'Application', 'CommandLineInterface', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__', '__version__', 'application', 'auto_suggest', 'buffer', 'buffer_mapping', 'cache', 'clipboard', 'completion', 'document', 'enums', 'eventloop', 'filters', 'history', 'input', 'interface', 'key_binding', 'keys', 'layout', 'mouse_events', 'output', 'prompt', 'prompt_async', 'reactive', 'renderer', 'search_state', 'selection', 'shortcuts', 'styles', 'terminal', 'token', 'utils', 'validation'] from prompt_toolkit import formatted_text Traceback (most recent call last): File "", line 1, in ImportError: cannot import name 'formatted_text' from 'prompt_toolkit' (/usr/lib64/python3.9/site-packages/prompt_toolkit/__init__.py) What am I missing here? TIA, Rich -- https://mail.python.org/mailman/listinfo/python-list
Re: bCNC
On 2020-12-30 18:35, Mark Bachman wrote:
I have installed Python 3.9.0 and 3.9.1 in an effort to install bCNC.
After entering the cmd prompt for installing bCNC the reply indicates
intsall was successful.
However when trying to launch bCNC with command prompt I get the following
reply.
Microsoft Windows [Version 10.0.19041.685]
(c) 2020 Microsoft Corporation. All rights reserved.
C:\Users\->py -m bCNC
new-config Utils
** On entry to DGEBAL parameter number 3 had an illegal value
** On entry to DGEHRD parameter number 2 had an illegal value
** On entry to DORGHR DORGQR parameter number 2 had an illegal value
** On entry to DHSEQR parameter number 4 had an illegal value
Traceback (most recent call last):
File
"C:\Users\\AppData\Local\Programs\Python\Python39\lib\runpy.py",
line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File
"C:\Users\-\AppData\Local\Programs\Python\Python39\lib\runpy.py",
line 87, in _run_code
exec(code, run_globals)
File
"C:\Users\--\AppData\Local\Programs\Python\Python39\lib\site-packages\bCNC\__main__.py",
line 60, in
from CNC import WAIT, CNC, GCode
File
"C:\Users\---\AppData\Local\Programs\Python\Python39\lib\site-packages\bCNC\CNC.py",
line 25, in
from svgcodeimport SVGcode
File
"C:\Users\-\AppData\Local\Programs\Python\Python39\lib\site-packages\bCNC\lib\svgcode.py",
line 13, in
import numpy
File
"C:\Users\-\AppData\Local\Programs\Python\Python39\lib\site-packages\numpy\__init__.py",
line 305, in
_win_os_check()
File
"C:\Users\---\AppData\Local\Programs\Python\Python39\lib\site-packages\numpy\__init__.py",
line 302, in _win_os_check
raise RuntimeError(msg.format(__file__)) from None
RuntimeError: The current Numpy installation
('C:\\Users\\--\\AppData\\Local\\Programs\\Python\\Python39\\lib\\site-packages\\numpy\\__init__.py')
fails to pass a sanity check due to a bug in the windows runtime. See this
issue for more information: https://tinyurl.com/y3dm3h86
C:\Users\-->
Any help would be greatly appreciated.
Did you read the page at https://tinyurl.com/y3dm3h86?
Basically, it's a known bug. Use numpy 1.19.3 instead of numpy 1.19.4:
py -m pip uninstall numpy
py -m pip install numpy==1.19.3
--
https://mail.python.org/mailman/listinfo/python-list
help
every time i try and open a .py file it just ciomes up with either modify, uninstall or repair. i have tried every single one of these and i have tried to install another version (it couldnt run on that version) and it just doesnt load up. if i try and open a new file it works but if i try and open a file that my friend made it just comes up with those options. please help ReplyForward -- https://mail.python.org/mailman/listinfo/python-list
Re: help
Hi, On Wed, Dec 30, 2020 at 4:40 PM BearGod777 wrote: > > every time i try and open a .py file How are you trying to open the py file? Also - I presume you are using Windows 10 + latest version of python, right? Thank you. > ReplyForward > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Which method to check if string index is queal to character.
On 2020-12-29, jak wrote: > > you could try this way: > > # --- > from dns import resolver as dns > > emails=['[email protected]', > '[email protected]'] > > for ue in emails: > try: > mxl = dns.resolve(ue.split('@')[1], 'MX') > except: > print(f'{ue}: bad mail server') > else: > if len(mxl) > 0: > print(f'{ue}: valid mail server') > # --- > > ... so, having verified the sever, you should only worry about the name. I actually have tried, that's good idea. -- Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: help
On 12/30/20 2:14 PM, BearGod777 wrote:
every time i try and open a .py file it just ciomes up with either modify,
uninstall or repair. i have tried every single one of these and i have
tried to install another version (it couldnt run on that version) and it
just doesnt load up. if i try and open a new file it works but if i try and
open a file that my friend made it just comes up with those options. please
help
you're rerunning the installer, don't do that.
that sounds rude. but isn't meant to be. somehow in recent times, the
installer program - whose job it is indeed to install, uninstall, repair
- is getting picked up by Windows when you try to run Python in certain
ways - the installer should certainly not be getting associated with .py
files as the way to run them. It might help diagnose how this happens if
you describe what you're doing ("try and open a .py file" doesn't say
enough, how are you trying to open it?)
open a command shell (cmd.exe or powershell) and run your script foo.py
with "py foo.py", assuming you chose to install the Python Launcher,
which you should do if using the Python that comes from python.org.
--
https://mail.python.org/mailman/listinfo/python-list
