I am beginner in Python. I am trying to build a sentiment analysis engine using Google's Natural Language API. I have followed their instructions, starting from creating a project to downloading the service account key. I have also read all the relevant posts here and in other forums, including Google's Github. However, the test run does not work as it says that the GOOGLE_APPLICATION_CREDENTIALS are not defined, despite executing $ export GOOGLE_APPLICATION_CREDENTIALS="PATH/service-account.json"
I checked with set | grep GOOGLE_APPLICATION_CREDENTIALS and I got the right response.
I checked the environment (printenv) and I see that the GOOGLE_APPLICATION_CREDENTIALS are included there with the right path.
I have also tried to set GOOGLE_APPLICATION_CREDENTIALS on my editor but it says the GOOGLE_APPLICATION is not defined:
import os
os.environ[GOOGLE_APPLICATION_CREDENTIALS]='/Users/jbarrigapartarrieu/Python/env/lib/Python3.7/service-account.json'
print(os.environ['GOOGLE_APPLICATION_CREDENTIALS'])
I am using Mac OS Sierra 10.13.6 and Python 3.7
Many thanks for all the help in advance!
Image of code:
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.
While reproducing steps from an interesting tutorial found online - Hyperledger Fabric 1.4 Tutorial - FabCar Sample Application, I have installed all Hyperledger Fabric binaries via the Curl command:
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s
From the Command Prompt window one can see that, the scripts are run correctly leading to the pull of hyperledger-docker images.
However, while launching the network from Visual Studio Code through the execution of
./startFabric.sh javascript from the fabcar sub-directory, one ends up with Fabric Images issues, which seems paradoxical.
A similar issue has been encountered, while attempting to bring up the network via the command
./network.sh up
from the test-network sub-directory too.
Thus, any relevant feedback would indeed be appreciated, given an absence of rationale to justify this matter.
[EDIT]
As a matter of fact, a synchronization issue might have caused the previously reported issue, since fabric-samples v.1.4.9 is not found from Curl command documented online. Thus the script automatically installs the latest Fabric binaries 2.x.
To rule out this issue, I have re-executed the Curl command by specifying the version 1.4.4 instead.
Therefore I can confirm, that the test-network sub-directory is not part of the Fabric binaries pertaining to the version 1.4x.
Furthermore, before the installation of this binaries, I had removed all containers, and related images, yielding to:
Back to the fabcar sub-directory, running:
./startFabric.sh javascript has still led to the following network issue :
What strikes me the most is:
firstly, that configtxlator can be found on my C:\Users\...\Documents\test4\fabric-samples\bin as opposed to the path highlighted on the command window.
secondly, I do not see the matter of version's incompatibility by scrutinizing byfn.sh:
Eventually, the manual amendment of IMAGETAG has not improved the situation.
Best
You seem to have the different version.
In hyperledger/fabric-samples, the test-network does not exist in version 1.4. In other words, you are running the code for the master version of fabric-samples (currently the version 2.x version). Since you're running the 1.4 tutorial, run the commands based on the 1.4 documentation and code.
fabric/docs/release-1.4
fabric/samples/release-1.4
[NOTE] It is also very likely that the different version binary has been installed. In the fabric document, the version can be specified and downloaded, so to download the binary of the corresponding version, you need to execute the command including the input parameter (version) below.
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s - 1.4.9 1.4.9 0.4.21
[EDIT - 1]
Prior to the explanation, in 1.4.x, first-network/byfn.sh exists, not test-network/network.sh. Change the branch of your fabric-samples to release-1.4.
Do not run 2.x code while doing the 1.4 tutorial.
./byfn.sh basically executes the image tag as latest. That is, if you have pulled the 2.x version of the image, even if you proceed to 1.4.x, it will run as 2.x.
cd fabric-samples
git checkout release-1.4
There are two ways.
tag the latest with 1.4.x image
Untag all hyperledger latest image tags, and tag 1.4.x images as latest.
(In fact, the easiest way is to delete both the 2.x and 1.4.x images and execute the command again.)
Or edit in byfn.sh
There is a part to set IMAGE_TAG in byfn.sh.
byfn.sh
# default image tag
# IMAGETAG="latest"
IMAGETAG="1.4.9"
Make sure the value of that part matches your 1.4.x version
[EDIT - 2]
For binary I don't know where and how you built it. However, you can easily build it on the fabric github.
make binaries
cd $GOPATH/src/github.com/hyperledger
git clone http://github.com/hyperledger/fabric
cd fabric
git checkout release-1.4
make native
Makefile
native - ensures all native binaries are available
configtxgen - builds a native configtxgen binary
configtxlator - builds a native configtxlator binary
cryptogen - builds a native cryptogen binary
idemixgen - builds a native idemixgen binary
peer - builds a native fabric peer binary
orderer - builds a native fabric orderer binary
Path setting
mv $GOPATH/src/github.com/hyperledger/fabric/.build/bin/* <your_bin_path>
# in my case
# mv $GOPATH/src/github.com/hyperledger/fabric/.build/bin/* usr/local/bin
or
export PATH=$PATH:$GOPATH/src/github.com/hyperledger/fabric/.build/bin
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.
Using node v 8.9.0 and this tutorial
When I try and debug my http google cloud function in dev tools:
C:_Users_Matt_AppData_Roaming_nvm_v8.9.0_node_modules_#google-cloud_functions-emulator_src_supervis
I get filesystem permission denied error, how can I debug my cloud functions:
I also got the filesystem permission denied error, and the issue was that you need to accept the premissions from chrome to be able to access that filesystem. initially I didn't see the premissions prompt, but then I found it on a different tab (which was kinda weird behavior). I guess just look for that permissions prompt, it should be right below your address bar.
I see that you are referring to a C directory, which means that you are trying this on Windows OS. I will put the steps below with documentation links on how to properly setup the configuration. Those steps worked for me well without giving me any issues, so I suggest you to follow them one by one and see if that helps you.
Run Google Cloud Functions Emulator on Windows OS:
Install and set up Google Cloud SDK for Windows. Link and documentation here
Install Node.js and npm for Windows. Tutorial here
Right click on Google Cloud SDK Shell and select Run as administrator.
Execute $ node --version you should get the version of Node.js without any additional errors
Execute $ npm --version you should get the version of npm without any additional errors
The tutorial that you are referring to is part of Google Cloud Functions Tutorial Series
First install and set up npm functions emulator by running $ npm install -g #google-cloud/functions-emulator as mentioned in Google Cloud Functions Tutorial : Setting up a Local Development Environment
Setup the project for the functions $ functions config set projectId PROJECT_ID as mentioned in Start and Stop the Emulator documentation.
Start the emulator by executing $ functions start. Same documentation as above.
Download the source code as mentioned in the documentation you are referring to. The GitHub repository is here.
Clone the project locally. $ git clone https://github.com/rominirani/googlecloudfunctions-training.git
Navigate to the folder $ cd googlecloudfunctions-training/helloworld-http
Follow the rest of the Google Cloud Functions Tutorial : Debugging Local Functions documentation.
NOTE: Whenever you run / execute / call the Cloud Function the Node.js
blank window will pop up. Keep it open as it is the executable that
executes your code.
I have tested the tutorial with the above set up that I described and it worked for me. You have to be the administrator of your account, since the Functions Emulator and the code is running locally, so you have to have all the permissions of the directories that are going to be used and execute all the software as administrator.
I'm trying to create a virtual environment to deploy a Flask app. However, when I try to create a virtual environment using virtualenv, I get this error:
Using base prefix '//anaconda'
New python executable in /Users/sydney/Desktop/ptproject/venv/bin/python
ERROR: The executable /Users/sydney/Desktop/ptproject/venv/bin/python is not functioning
ERROR: It thinks sys.prefix is '/Users/sydney/Desktop/ptproject' (should be '/Users/sydney/Desktop/ptproject/venv')
ERROR: virtualenv is not compatible with this system or executable
I think that I installed virtualenv using conda. When I use which virtualenv, I get this
//anaconda/bin/virtualenv
Is this an incorrect location for virtualenv? I can't figure out what else the problem would be. I don't understand the error log at all.
It turns out that virtualenv just doesn't work correctly with conda. For example:
https://github.com/conda/conda/issues/1367
(A workaround is proposed at the end of that thread, but it looks like you may be seeing a slightly different error, so maybe it won't work for you.)
Instead of deploying your app with virtualenv, why not just use a proper conda environment? Conda environments are more general (and powerful) than those provided by virtualenv.
For example, to create a new environment with python-2.7 and flask in it:
conda create -n my-new-env flask python=2.7