pyodbc has a .pyi file but when running pytest-mypy, I have this error:
__________________________________________________________________________________________________ connexion.py __________________________________________________________________________________________________
3: error: Cannot find implementation or library stub for module named "pyodbc"
3: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
_
This should only happen when the library doesn't have stub files but it appears there are stub files. What should I do?
I'm using Python 3.10.2 and i've updated pyodbc to the latest version (pyodbc==4.0.34)
Let's assume your python is installed in /usr. In that case, your python executable will be in /usr/bin, and any libraries you install with pip will be installed in /usr/lib/python3.10/site-packages. In this case, all the sources for pyodbc can be found in /usr/lib/python3.10/site-packages/pyodbc.
Following this pattern we would expect to find type stubs in /usr/lib/python3.10/site-packages/pyodbc.pyi, but there is an issue in pyodbc, so that the stubs are actually installed in /usr/pyodbc.pyi.
In order to pick up this path, you will need to modify settings in your development environment. In Linux, try setting PYTHONPATH=/usr in your environment. The link mentioned in rogdham's comment includes others' comments on how to make this work in VS Code. Other development environments should support similar workarounds.
Related
I am trying to get the MNIST dataset in Julia using the MLDatasets package via the following commands in a .jl file:
using MLDatasets
dataset_train = MNIST(:train)
dataset_test = MNIST(:test)
This is what's indicated in the MLDatasets documentation. However, I am getting the following error:
ERROR: MethodError: objects of type Module are not callable
Stacktrace:
[1] top-level scope
# c:\my\julia\file\...
For some reason Julia is interpreting MNIST to be a module. It is worth noticing that this exact same code works without problem in a friend's computer, who has the same operating system, and the same Julia version (OS: Windows, x86_64-w64-mingw32; Julia version: 1.8.2).
The MLDatasets package is installed and does import correctly with the using command. What may be the problem?
The most likely reason is that you have an older version of MLDatasets installed on your computer. The current version is 0.7.5, while you probably have a 0.5.x version installed. This can happen if there are package conflicts that prevent the latest version of MLDatasets from being installed.
If you're using the default v1.8 environment to install all packages, conflicts like this are more likely to happen. It's recommended to instead create a separate environment for your project, and install only the packages you need for that particular project in that environment.
Older versions of MLDatasets had MNIST as a sub-module rather than as a type, which is the reason for this particular error message.
You can compare your environment's status (] status) and the one in your friend's setup. ] status --outdated can also help you see which particular package is causing the issue here. But I would suggest just keeping your base Julia environment (v1.8) minimal, uninstalling packages except the ones that you need to be available everywhere (eg. IJulia). See also the "Creating your own projects" section of the Pkg documentation.
I'm trying to use VSCode Remote extension to connect to a remote host that runs on RHEL/CentOS 6, but it fails to connect since CentOS 6 ships with GLIBC 2.12 and GLIBCXX 3.4.1. As mentioned in this post, in order to get the extension to work, the workaround is to install GLIBC>=2.17 and GLIBCXX>=3.4.18.
Unfortunately, I don't have sudo access for the server, so I won't be able to update these libraries using the bash script provided in the link. Also, in this SO post, the author says not to update the system GLIBC since it can break down system applications. That being said, I've tried something different -- I extracted those rpm packages, as described in this blog, inside my home folder. I've then updated the env variables PATH and LD_LIBRARY_PATH in ~/.bash_profile to point to these new locations. But the node binary (in VS Code Remote) still can't find these libraries.
Is there a way to let the node binary know where to look for these libraries? More precisely, can someone explain how I can make this extension work without sudo access?
I've got it to work by installing gcc and glibc using Linuxbrew. See this post for more details: https://github.com/microsoft/vscode-remote-release/issues/103#issuecomment-546551293.
Couple of things to take note of:
Node binary versions in VS Code Server may vary between commits. In the GitHub comment above, the author uses node#10 -- you may replace it with node#12; everything would still work.
Make sure glibc and gcc are properly installed using linuxbrew. This step is key.
System Info:
MongooseIM version: 3.0.0
Installed from: pkg
Erlang/OTP version: 18
Ubuntu 16.04
I am having trouble creating a standard base for a custom module. I want to create a simple hello world program as outlined in the documentation for ejabberd.
However, I cannot get it to work for MongooseIM. Are there any instructions for how to do this? As a beginner I am just looking for building blocks to creating my own modules, and everything I look at is a little too complex for what I am trying to achieve at the moment.
Here is the code for my module: (taken from ejabberd) https://docs.ejabberd.im/developer/extending-ejabberd/modules/#mod-hello-world
And here is my log error:
I have added the following line in my config file with all other running modules:
{mod_hello_world, []}
I am assuming it has something to do with the compilation and there being no .beam file created for the modules as well as some syntax errors specific to MongooseIM. I am also unfamiliar with documentation for compiling modules when using a pre-built pkg as opposed to installing from source.
DISCLAIMER: I'm a MongooseIM developer working for Erlang Solutions.
The link you posted hints at the answer to the immediate question:
If you compiled ejabberd from source code, you can copy that source code file with all the other ejabberd source code files, so it will be compiled and installed with them. If you installed some compiled ejabberd package, you can create your own module dir, see Managing Your Own Modules.
MongooseIM (a.k.a. MIM) does not support the latter method of managing modules, i.e. it's not possible to drop source code into some predefined location when MIM is installed from a package and let it just compile and run the module. If we want to write a custom module, we have to build MongooseIM from source.
To be precise, we don't have to build the whole server from source and package it ourselves. We have to, however, clone the repository, place the new module source there (due to build time requirements like header files) and build it there. Once we get a .beam file of the new module we can just drop it into an installed MongooseIM's code path.
To be even more precise, let's say we have installed MIM from mongooseim_3.0.0-1~ubuntu~artful_amd64.deb available from the Downloads page at erlang-solutions.com, therefore we want to build a module compatible with 3.0.0:
Clone MIM: git clone https://github.com/esl/mongooseim
cd mongooseim
git checkout 3.0.0
Place mod_hello_world.erl under ./src/
rebar3 compile
Once rebar3 finishes get ./_build/default/lib/mongooseim/mod_hello_world.beam and copy to the target host where we installed MIM from a package.
Please note, though, that an example taken straight from ejabberd documentation might not work "as is" in MongooseIM. In this simple module, for example, we'll not be able to include logger.hrl as MongooseIM doesn't have such a header file - we would have to -include("mongoose_logger.hrl"). instead.
I want to compile quickfix library, I don't have any MySQL installed on my computer and it is not necessary for me. I tried to disable the mysql from the configure --without-mysql but when I compile, I still see -lmysqlclient in my compiling command and it eventually fails because I don't have this library file. How can I disable this?
Also, if I tried to compile with old gcc4.1.2 (newer version like 4.8 is fine), but I cannot even generate the configure file but keeps seeing this error:
configure: error: unable to find set_terminate in std or global namespace
There should be any problem with this compiler because I can compile many other things and I have to use this version of the compiler because many of my libraries are compiled under this version.
I assume, you want to compile C++ source codes - http://www.quickfixengine.org/quickfix/doc/html/building.html. The tutorial indicates that MySQL is optional. To install MySQL support, you need to explicitly add --with-mysql flag. There is not --without-mysql flag.
I still cannot get PyDev and eclipse on MacOS to reliably import modules.
import csv generates an "Unresolved import:" error within PyDev; however, when I open Terminal and run the script from the interpreter it works fine.
PyDev is using the interpreter found at /usr/bin/python, which is pointing to Python 2.7.
The relevant files (csv.pyc and csv.pyo) are in /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7, which is in PYTHONPATH.
Actually, for the standard library, PyDev needs the .py files (from your description you only have the .pyc/.pyo files) -- it should give you a big warning when you try to configure an interpreter where the .py files are not available.
So, the recommended solution would be using a python distribution from http://python.org (instead of the default which comes with Mac OS) or grab the standard library from elsewhere and copy it over to where you have the standard library in Mac OS.
See the "IMPORTANT for Mac users" note at: http://pydev.org/manual_101_interpreter.html
Everytime you add a new module, you need to reconfigure the interpreter in PyDEV. Whenever you do that, don't forget to check the new module you are adding to make sure it's being added to the PYTHON PATH.
Alternatively, you can configure each project by adding the new module to it. But that means you will have to configure this on a project basis. I would do it the other way.