I am working on an app which has frontend (angularjs) and backend(python, flask framework). I am creating a Makefile for this app.
To install backend dependencies using requirements.txt file, I want to check if virtualenv has been activated or not.
If virtualenv is activated then only installs dependencies using requirements.txt file otherwise not.
dummy:
if virtualenv_activated:
install_dependencies
I checked this link: running inside virtualenv but didn't understand much about writing this in Makefile.
Any useful help will be appreciated!
Finally I found out the way to do this, we can write it as:
ifeq ($(VIRTUAL_ENV), )
#echo "virtual env is not activated"
else
#echo "virtual env is activated"
endif
So, this way we can check for virtual_env activation.
Thanks!
Related
I recently developed a package my_package and am hosting it on GitHub. For easy installation and use, I have following setup.py:
from setuptools import setup
setup(name='my_package',
version='1.0',
description='My super cool package',
url='https://github.com/my_name/my_package',
packages=['my_package'],
python_requieres='3.9',
install_requires=[
'some_package==1.0.0'
])
Now I am trying to install this package in a conda environment:
conda create --name myenv python=3.9
conda activate myenv
pip install git+'https://github.com/my_name/my_package'
So far so good. If I try to use it in the project folder, everything works perfectly. If I try to use the packet outside the project folder (still inside the conda environment), I get the following error:
ModuleNotFoundError: No module named 'my_package'
I am working on windows, if that matters.
EDIT:
I'm verifying that both python and pip are pointing towards the correct version with:
which pip
which python
/c/Anaconda3/envs/my_env/python
/c/Anaconda3/envs/my_env/Scripts/pip
Also, when I run:
pip show my_package
I get a description of my package. So pip finds it, but as soon as I try to import my_package in the script, I get the described error.
I also verified that the package is installed in my environment. So in /c/Anaconda3/envs/my_env/lib/site-packages there is a folder my_package-1.0.dist-info/
Further: python "import sys, print(sys.path)"
shows, among other paths, /c/Anaconda3/envs/my_env/lib/site-packages. So it is in the path.
Check if you are using some explicit shebang in your script pointing to other Python interpreters.
Eg. using the system default Python:
#!/bin/env python
...
While inside your environment myenv, try to uninstall your package first, to do a clean test:
pip uninstall my_package
Also, you have a typo in your setup.py: python_requieres --> python_requires.
And I actually tried to install with your setup.py, and also got ModuleNotFoundError - but because it didn't properly install due to install_requires:
ERROR: Could not find a version that satisfies the requirement some_package==1.0.0
So, check also that everything installs without errors and warnings.
Hope that helps.
First thing I would like to point out (not the solution) regards the following statement you made:
If I try to use it in the project folder [...] If I try to use the packet outside the project folder [...]
I understand "project folder" means the "my_package" folder (inside the git repository). If that is the case, I would like to point out that you are mixing two situations: that of testing a (remote) package installation, while in your (local) repository. Which is not necessarily wrong, but error-prone.
Whenever testing the setup/install process of a package, make sure to move far from your repository (say, "/tmp/" equivalent in Windows) and, preferably, use a fresh environment. That will eliminate "noise" in your tests.
First thing I would tell you to do -- if not already -- is to create a fresh conda env and install your package from an empty/new folder. Eg,
$ conda env create -n test_my_package ipython pip
$ cd /tmp # equivalent temporary or new in your Windows
$ pip install git+https://github.com/my_name/my_package
If that doesn't work (maybe a problem with your pip' git+http code), do another way: create a release for your package (eg, "v1") and then install the released version by indicating the zip package URL (that you get from your "my_package" releases page on Github):
$ pip install https://github.com/my_name/my_package/archive/v1.zip
I am trying to build (and later upload) a conda package which would contain my custom program that I have developed in C++.
Simplifying the problem, I have a following meta.yaml:
package:
name: CoolName
version: "1.0.0"
source:
path: ./source
requirements:
build:
- make
and the following build.sh:
make
I have two questions here:
1) How and where should I copy the binary which is a result of the make compilation so that it is indeed recognized upon environment activation?
2) How should I specify g++ as a dependancy? I would like to have this package be later available for linux-64 and osx-64... In the building process (in the Makefile) I am using only g++.
Edit
I have modified my build script to have:
make
mkdir -p $PREFIX/bin
cp my_binary $PREFIX/bin/my_binary
And now the conda-build is successful. However, when I later try to install the package locally with conda install --use-local I get:
Collecting package metadata (current_repodata.json): done
Solving environment: done
# All requested packages already installed.
But this is not true, my binary is not installed anywhere and is not recognized...
How and where should I copy the binary which is a result of the make compilation so that it is indeed recognized upon environment activation?
As you mentioned in your edit, install somewhere within ${PREFIX}
How should I specify g++ as a dependancy?
To use conda-supplied compilers (rather than your system compiler), use this:
requirements:
build:
- {{ compiler('cxx') }}
I would like to have this package be later available for linux-64 and osx-64... In the building process (in the Makefile) I am using only g++.
Note: On Mac, it will use clang++, not g++. Make sure your Makefile respects the ${CXX} environment variable instead of hard-coding g++.
However, when I later try to install the package locally with conda install --use-local I get:
That is strange. conda install --use-local CoolName should do what you want. But here are some things to try:
Double-check the contents of the environment you're trying to install it into:
conda list
Try installing to a fresh environment:
conda create -n my-new-env --use-local CoolName
Delete any obsolete versions of the package you might have created before you successfully built the package:
# Inspect the packages you've created,
# and consider deleting all but the most recent one.
ls $(conda info --base)/conda-bld/linux-64/CoolName*.tar.bz2
...then try running conda install again.
If I had a compiled Golang program that I wanted to install such that I could run it with a bash command from anywhere on my computer, how would I do that? For example, in nodejs
npm install -g express
Installs express such that I can run the command
express myapp
and express will generate a file directory for a node application called "myapp" in whatever my current directory is. Is there an equivalent command for go? I believe now with the "go install" command you have to be in the directory that contains the executable in order to run it
Thanks in advance!
Update: If you're using Go 1.16, this answer still works, but go install has changed and is now the recommended method for installing executable packages. See Karim's answer for an explanation: https://stackoverflow.com/a/68559728/10490740
Using Go >= 1.11, if your current directory is within a module-based project, or you've set GO111MODULE=on in your environment, go get will not install packages "globally". It will add them to your project's go.mod file instead.
As of Go 1.11.1, setting GO111MODULE=off works to circumvent this behavior:
GO111MODULE=off go get github.com/usr/repo
Basically, by disabling the module feature for this single command, it will install to GOPATH as expected.
Projects not using modules can still go get normally to install binaries to $GOPATH/bin.
There's a lengthy conversation and multiple issues logged about this change in behavior branching from here: golang/go - cmd/go: go get should not add a dependency to go.mod #27643.
Starting with Go >= 1.16 the recommended way to install an executable is to use
go install package#version
For example, go install github.com/fatih/gomodifytags#latest.
Executables (main packages) are installed to the directory named by the GOBIN environment variable, which defaults to $GOPATH/bin or $HOME/go/bin if the GOPATH environment variable is not set. You need to add this directory to your PATH variable to run executables globally. In my case, I've added this line to my ~/.zshrc file. (if you are using bash, add it to the ~/.bash_profile file):
export PATH="$HOME/go/bin:$PATH"
Go team published a blog post about this change, here's the explanation quote:
We used to recommend go get -u program to install an executable, but this use caused too much confusion with the meaning of go get for adding or changing module version requirements in go.mod.
Refer to go install documentation for more details
As far as I know, there is no direct equivalent to npm install -g. The closest equivalent would not be go install, but go get. From the help page (go help get):
usage: go get [-d] [-f] [-fix] [-insecure] [-t] [-u] [build flags] [packages]
Get downloads and installs the packages named by the import paths,
along with their dependencies.
By default, go get installs binaries to $GOPATH/bin, so the easiest way to make those binaries callable from everywhere is to add that directory to your $PATH.
For this, put the following line into your .bashrc (or .zshrc, depending on which shell you're using):
export PATH="$PATH:$GOPATH/bin"
Alternatively, you could also copy or link the executables to /usr/local/bin:
ln -s $GOPATH/bin/some-binary /usr/local/bin/some-binary
Short solution for Linux users:
Use the go get command as usual
Add the following lines to .bashrc:
# This is the default GOPATH, you should confirm with the 'go env' command
export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
Restart terminal or source it. Installed binaries will be available globally.
For Go v1.8+
go install package_name#latest
Caveat: this answer is outdated following the 2020 deprecation of go get. The solution presented here won't work with newer Go runtime installs.
The closest analogue of this in Go would be go get. By default, it will fetch a Go package from a supplied repository URL, and requires a $GOPATH variable to be set in your shell so that Go knows where to store the packages (and subsequently where to find them when compiling code depending on go get-ted packages).
Example syntax:
$ go get github.com/user/repo
The behaviour supplied by npm's -g flag is default, and packages installed using go get are normally available globally.
See go get --help for more information about the command.
As mentioned by #helmbert, adding your $GOPATH to your $PATH is useful if you're installing standalone packages.
if you are using zsh :
first: install your package using :
go install package#version
then , you edit your .zshrc file
nano ~/.zshrc
Add this line to the end of .zshrc file :
export PATH="$HOME/go/bin:$PATH"
last but not least :
source ~/.zshrc
then open a new terminal and execute your command :)
TL;DR at the bottom. I'm going to walk you through how I came to this conclusion, and why the more obvious solutions don't work.
Upon seeing this question, I thought "If I could set root's GOPATH=/usr, it would install things in /usr/bin/ and /usr/src!"
So I tried the obvious thing:
Add GOPATH=/usr to root's .bashrc.
And it worked!
Sort of.
Not really.
Turns out, sudo doesn't execute root's .bashrc. For "security" or something like that.
Do env_set or something in /etc/sudoers
Turns out, /etc/sudoers can only remove environment variables. There's no env_set directive.
(As far as I can find)
Dig through man sudoers.
Where does sudo get it's default set of environment variables from?
Well, the first one in the list is /etc/environment, so that's the one I used.
sudo echo "GOPATH=/usr" >> /etc/environment
sudo go get <repo>
Binaries will be put in /usr/bin, and sources will be put in /usr/src.
Running go as non-root will use GOPATH the "normal" way.
If you don't have go installed, you may use the gobinaries. it builds an on-demand binary of the project from github repo.
The command to install the go package would be:
curl -sf https://gobinaries.com/rakyll/hey | sh
I usually write a makefile with an install target so that one can build and install with make && make install. This works for Shell and C projects. However, when I use Python, I usually write a setup.py to install the modules correctly.
In the makefile, I would like to call ./setup.py install, I am not sure how to get all the parameters form the makefile, like DESTDIR right. Debian uses some special magic, when I package something with only a setup.py in it. Having a makefile present uses makefile magic.
Or is it possible to call rst2man and gzip and install those files into $(DESTDIR)/usr/share/man from setup.py? Then I could put everything into the setup.py.
How do I combine the two?
By default, setup.py installs modules into sys.prefix (you can have different Pythons with different sys.prefix).
You can override that with --prefix argument to setup.py.
E.g.:
build :
cd module && CPPFLAGS=${CPPFLAGS} python setup.py build --prefix=${PREFIX}
install :
cd module && CPPFLAGS=${CPPFLAGS} python setup.py install --prefix=${PREFIX}
See How installation works for more details.
I'm trying to put together a custom buildpack with NodeJS and the CouchBase module/libraries
I've gotten as far as using Vulcan to build libcouchbase and libvbucket and getting the buildpack to retrieve and unpack the tgz files for both.
Everything looks ok there, but I receive errors when npm tries to install the couchbase module:
I get a bunch of errors, but this line:
"../src/couchbase_impl.h:52:36: warning: libcouchbase/couchbase.h: No such file or directory"
leads me to think that it can't find the libcouchbase libraries (which is possible since they aren't in the usual place).
I've tried to add the correct path using CPPFLAGS="-I/app/vendor/couchbase/include/libcouchbase" in both the Config Vars and just exporting that as part of the compile phase, but still no luck.
Here is the gist with the Heroku deploy output and the compile/release buildpack files:
https://gist.github.com/ahamidi/5620503
Any help would be greatly appreciated.
Thanks,
Ali
[Update 1]
I've made some progress and I can now get the slug to compile when deploying to Heroku.
The key was figuring out the ENV Variables that CouchNode looks for when adding custom directories to include.
In this case, the Env Variables were EXTRA_CPPFLAGS and EXTRA_LDFLAGS.
So I updated the compile file to include the following:
export EXTRA_CPPFLAGS="-I$BUILD_DIR/vendor/couchbase/include"
export EXTRA_LDFLAGS="-L$BUILD_DIR/vendor/couchbase/lib -Wl,-rpath,$BUILD_DIR/vendor/couchbase/lib"
The slug compiles and the app is deployed, but I now get a different error in the logs:
Error: libcouchbase.so.2: cannot open shared object file: No such file or directory
So it looks like Node can't see the libcouchbase libraries directory.
For anyone who is curious or experiencing a similar issue, here's what worked for me.
In order to get the couchbase npm module to install I had to tell it where to find the libcouchbase libraries (in compile file):
export EXTRA_CPPFLAGS="-I$BUILD_DIR/vendor/couchbase/include"
export EXTRA_LDFLAGS="-L$BUILD_DIR/vendor/couchbase/lib -Wl,-rpath,$BUILD_DIR/vendor/couchbase/lib"
Then in order to require couchbase in my app I had to set the following Env Variable:
LD_LIBRARY_PATH="/app/vendor/couchbase/lib:$LD_LIBRARY_PATH"
With the command:
heroku config:add LD_LIBRARY_PATH="/app/vendor/couchbase/lib:$LD_LIBRARY_PATH"
You should set CPPFLAGS="-I/app/vendor/couchbase/include" LDFLAGS="-L/app/vendor/couchbase/include -lcouchbase"
from your script it seems like you just unpacking libcouchbase without any further work. you should also build it and install. typical magic spell for node.js client will be ./configure --disable-plugins --disable-examples && make && sudo make install. I'm not sure if sudo part needed on heroku, probably just make install