Mypy raises syntax error with pydrake stub - mypy

When I try to run mypy in my project that has PyDrake as a depencency I get: venv/lib/python3.9/site-packages/pydrake/common/eigen_geometry.pyi:30: error: invalid syntax
The line in questions is: def cast[AutoDiffXd](self, *args, **kwargs) -> Any: .... I'm assuming this has something to do with PyDrake's custom templating system. How can I make MyPy and PyDrake play nice?
Environment Info
OS: Ubuntu 20.04
Python version: 3.9.16
MyPy version: 0.991
Drake version: 1.11.0

As of the current version of Drake (v1.12.0), we unfortunately do not support Mypy. The purpose of the *.pyi files as of today is solely to enable VSCode suggestion auto-complete.
We didn't have a central issue tracking this, so I've filed a new one. Hopefully we can remove the syntax errors down the road.
The only work-around I know of for today is to delete the *.pyi files if you use Mypy.

Related

mypyc, KeyError: '__file__'

I successfully use mypyc in my project and it has performed well until just a couple days ago. I now get the following error:
File "mypyc/__main__.py", line 18, in <module>
KeyError: '__file__'
Line 18 above, i.e., the line that is failing, is just
base_path = os.path.join(os.path.dirname(__file__), '..')
which I wouldn't expect to fail. I am in my venv virtualenv when I execute mypyc using the same command as has always worked before.
I thought perhaps a regression was introduced in mypyc so I used git to go back in time to see if that line had changed in any recent version of mypy, but it hadn't.
I also tried downgrading mypy to an older version that worked before but that version also failed with the same error. To be sure it wasn't being experienced by others I also checked the issues at the mypy repo on github and did a search for __file__ to see if that part of the error message showed up and it didn't. Perhaps it is some weird issue with my environment?
I experience the issue with venv virtualenvs created with Python 3.10, 3.10.1 but also 3.9.9 too. It worked fine on Python 3.10 before. Any ideas on what to investigate next?

nbsphinx causes build to fail when building Jupyter Notebooks

Details
I am getting a build failure of my read-the-docs that I don't understand. The assertion of "verbatim" in line 2151 of nbsphinx.py is causing the build failure. So the build fails when I try to include the Jupyter Notebook tutorials I created. I compared current versions of the tutorials to previous versions which had not caused the build to fail, and I can't find a difference that could account for the current failure.
Read the Docs project URL: lofti_gaia
Build URL: https://github.com/logan-pearce/lofti_gaia
Read the Docs username: logan-pearce
Expected Result
A passing build including *.ipynb files
Actual Result
Build failed at line 2151 of nbsphinx.py due to assertion of 'Verbatim' failing.
Terminal output:
Running Sphinx v4.1.2
loading translations [en]... done
making output directory... done
WARNING: html_static_path entry '_static' does not exist
loading pickled environment... done
building [mo]: targets for 0 po files that are out of date
building [latex]: all documents
updating environment: 0 added, 0 changed, 0 removed
looking for now-outdated files... none found
processing lofti_gaia.tex... index installation tutorials/QuickStart tutorials/Tutorial api lofti loftitools
resolving references...
done
writing... failed
Exception occurred:
File "/home/docs/checkouts/readthedocs.org/user_builds/lofti-gaia/conda/latest/lib/python3.7/site-packages/nbsphinx.py", line 2151, in depart_codearea_latex
assert 'Verbatim' in lines[0]
AssertionError
The full traceback has been saved in /tmp/sphinx-err-x1h83s3m.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
According to the github issue 584 for nbsphinx (https://github.com/spatialaudio/nbsphinx/issues/584), this is due to a compatibility issue with sphinx 4.1.0. It can be gotten around by requiring sphinx version 4.0.2.
So in my requirements.txt file, I included sphinx==4.0.2, after which the build passes. So now my requirements.txt file looks like:
numpy
matplotlib
astropy>=4.0.1.post1
astroquery>=0.4
sphinx==4.0.2
ipython==7.19.0
nbsphinx>=0.8.6
and the build passes.
I have encountered the same issue. I did not solve it with .ipynb format, but converting the jupyter notebook to .rst format works.
May it helps

Openstack placement-status upgrade check giving not initialized error

I am trying to install openstack Wallaby on Ubuntu 20.04. I already installed Keystone and Glance and they work as expected. But after I installed Placement and tried to verify it using 'placement-status upgrade check' I constantly get the same error.
Error:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/oslo_upgradecheck/upgradecheck.py", line 196, in run
return conf.command.action_fn()
File "/usr/lib/python3/dist-packages/oslo_upgradecheck/upgradecheck.py", line 104, in check
result = func_name(self, **kwargs)
File "/usr/lib/python3/dist-packages/oslo_upgradecheck/common_checks.py", line 41, in check_policy_json
policy_path = conf.find_file(conf.oslo_policy.policy_file)
File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 2543, in find_file
raise NotInitializedError()
oslo_config.cfg.NotInitializedError: call expression on parser has not been invoked
Is this normal at this stage or am I doing something wrong here?
I already checked the database connections (user and password work and database is made). And I also checked the username, password and url options in keystone_authtoken in placement.conf but I can't find what's wrong.
I also encountered this problem with Wallaby on Ubuntu 20.04. I solved it with installing Placement from PyPI instead of Ubuntu package manager so far. You should consider how implement starting Placement automatically if you install Placement from this instruction.
Install and configure Placement from PyPI
https://docs.openstack.org/placement/wallaby/install/from-pypi.html
I had the same problem so changed to Victoria, same issue. Digging about in the docs though I found the issue. The command that populate the database looks similar for Keystone, Glance and Placement but for placement the command should be 'su -s /bin/sh -c "placement-manage db sync" placement'. Notice that for placement it is 'db sync' not 'db_sync' as it is for the others. I created scripts, well actuall am using ansible and just cut and pasted between them and my guess is you have done the same. Basically as it does not run the database is empty hence the error.
Guy

command line compiling generates bigger file than the online version

I am testing google closure compiler on command line.
I took the latest version :
java -jar closure-compiler.jar --version
Closure Compiler (http://github.com/google/closure-compiler)
Version: v20190618
Built on: 2019-06-21 17:24
I am generating a compressed version of my javascript like this :
java -jar closure-compiler.jar my_script.js > out.js
The problem is that the generated code is bigger than the one I get when I use the online service at https://closure-compiler.appspot.com/home
I noticed that the command line version added, at the beginning, the following code :
var $jscomp=$jscomp||{};$jscomp.scope={};$jscomp.findInternal=function(a,c,b){a instanceof String&&(a=String(a));for(var d=a.length,e=0;e<d;e++){var f=a[e];if(c.call(b,f,e,a))return{i:e,v:f}}return{i:-1,v:void 0}};$jscomp.ASSUME_ES5=!1;$jscomp.ASSUME_NO_NATIVE_MAP=!1;$jscomp.ASSUME_NO_NATIVE_SET=!1;$jscomp.SIMPLE_FROUND_POLYFILL=!1;
$jscomp.defineProperty=$jscomp.ASSUME_ES5||"function"==typeof Object.defineProperties?Object.defineProperty:function(a,c,b){a!=Array.prototype&&a!=Object.prototype&&(a[c]=b.value)};$jscomp.getGlobal=function(a){return"undefined"!=typeof window&&window===a?a:"undefined"!=typeof global&&null!=global?global:a};$jscomp.global=$jscomp.getGlobal(this);
$jscomp.polyfill=function(a,c,b,d){if(c){b=$jscomp.global;a=a.split(".");for(d=0;d<a.length-1;d++){var e=a[d];e in b||(b[e]={});b=b[e]}a=a[a.length-1];d=b[a];c=c(d);c!=d&&null!=c&&$jscomp.defineProperty(b,a,{configurable:!0,writable:!0,value:c})}};$jscomp.polyfill("Array.prototype.find",function(a){return a?a:function(a,b){return $jscomp.findInternal(this,a,b).v}},"es6","es3");
I do not have such a code in my script: Where does it come from ?
how can I produce the same output as the online version ?
To get the compiler command line work as the web service, I just added an option :
--language_out=ECMASCRIPT_2015
This is likely a discrepancy between the settings on the web service and the ones you're using locally.
Have a look at a Closure Compiler: Flags and Options to see what settings you might prefer.
If you'd share your source, it'd be possible to try and help you narrow down the options.
As for the extra code, I believe it is at least partially a polyfill for Array.prototype.find (aka [].find), which I assume is in your code?
If so, that's Closure injecting code to improve your cross browser compatibility.

New version of OpenSSL causes Plone/Zope to not start

Today's (1 Mar 2016) OpenSSL release has caused the following error when running Plone/Zope
.buildout/eggs/ZODB3-3.10.5-py2.7-linux-x86_64.egg/persistent/cPersistence.so: undefined symbol: SSLv2_method
It's hard to see what's going on since it's a binary file. I also tried updating to ZODB3 3.11.0 which yields the following traceback
.buildout/eggs/ZConfig-2.9.0-py2.7.egg/ZConfig/loader.py", line 217, in schemaComponentSource
package=package)
ZConfig.SchemaResourceError: could not load package ZServer:
.buildout/eggs/zope.security-3.7.4-py2.7-linux-x86_64.egg/zope/security/_proxy.so: undefined symbol: SSLv2_method
Package name: 'ZServer'
File name: 'component.xml'
Package path: None
Is there any workaround for this other than reverting OpenSSL?
zope security is a compiled egg, like all the ones ending with -py2.7-linux-x86_64.egg.
As the traceback says, it cannot find anymore a symbol.
Probably you have to recompile it with the new openssl-dev.
I would try (on a development server first):
backup your compiled egg (mkdir eggs-backup && mv `eggs/zope.security-3.7.4-py2.7-linux-x86_64.egg eggs-backup/)
rerun buildout
This will recompile your missing egg.
Hopefully it works and hopefully it is the only one linked to that library.
Anyway, dependending on the way you patched openssl you may have a lot of other issues (I am thinking about Python, urllib*, curl, wget, ...)
OpenSSL 1.0.2g by default doesn't build with SSLv2 (because of the recent DROWN attack). You may need to manually build it without OPENSSL_NO_SSL2 flag.
(but in fact you shouldn't do this if you're doing some server-related stuff, there is a serious security reason because of which it was disabled, see https://drownattack.com)
I was able to resolve this by upgrading python to 2.7.10+, and then upgrading Pillow and lxml.

Resources