Git install python packages


#1

Hi,

As a chef user I thought I would give this a try. Docs are not clear. Any other framework I would have given up but I will give one more shot. This framework is not critical my any stretch of the imagination so unless docs are cleaned up I dont expect wide adoption esp for python devs.

That being said…

I can build a plan and export. I ssh into the container to find my pip install libs. Guess what they are nowhere to be found despite the below. So how do I do a simple pip install?

Requirement already satisfied: flask==0.12.2 in /hab/pkgs/core/python2/2.7.15/20181212185420/lib/python2.7/site-packages (from -r /hab/pkgs/david/flask/0.1.0/20181223112622/app/requirements.txt (line 1)) (0.12.2)

Requirement already satisfied: redis in /hab/pkgs/core/python2/2.7.15/20181212185420/lib/python2.7/site-packages (from -r /hab/pkgs/david/flask/0.1.0/20181223112622/app/requirements.txt (line 2)) (3.0.1)

Requirement already satisfied: itsdangerous>=0.21 in /hab/pkgs/core/python2/2.7.15/20181212185420/lib/python2.7/site-packages (from flask==0.12.2->-r /hab/pkgs/david/flask/0.1.0/20181223112622/app/requirements.txt (line

pkg_name=flask
pkg_origin=sfsfgsfg
pkg_version=“0.1.0”
pkg_maintainer=“The Habitat Maintainers humans@habitat.sh
pkg_license=(“Apache-2.0”)

pkg_build_deps=(core/coreutils core/gcc core/python2)

pkg_deps=(
core/python2
)

do_download() {
return 0
}
do_verify() {
return 0
}
do_clean() {
return 0
}

do_build() {
pip install --upgrade pip
}

do_install() {

The application exists as a single file in the directory. A real application

would likely a single app directory or a few directories.

app_dir=$pkg_prefix/app
mkdir $app_dir
cp index.py $app_dir/
cp requirements.txt $app_dir/
cp app.py $app_dir/
cd $pkg_prefix
pip install -r $app_dir/requirements.txt
}


#2

It looks like you’re installing your pip deps into the global python installation, which lives in the core/python package. When you export, you’re using a clean version of core/python without these added packages. That’s obviously not what you’re going for.

Consider using a virtual environment. Virtual envs are generally best practice no matter where/how you’re deploying Python. I’m building Python services and CLI tools with Habitat without any issue. Here’s roughly how I do it:

For services:

do_install() {
    mkdir -p $pkg_prefix
    # copy all service files into $pkg_prefix (usually from $PLAN_CONTEXT/..)
    cd $pkg_prefix
    python -m venv venv
    source ./venv/bin/activate
    pip install -r path/to/requirements.txt
}

In the service’s init hook, symlink all the service files and venv folder into the service’s var directory, {{pkg.svc_var_path}}. In the run hook, cd into the service’s var directory, source env/bin/activate, and start your service as you normally would.

For CLI tools:

pkg_bin_dirs=(bin)
do_install() {
    cd $pkg_prefix
    python -m venv .
    source ./bin/activate
    pip install "${PLAN_CONTEXT}/.."
    # where the habitat directory is in the top level of the python package, next to setup.py
}

If you have shell entrypoints configured in your package, the binstubs will be put in $pkg_prefix/bin, which makes it easy to binlink globally or hab pkg exec.

Note: the venv module is only included by default in Python 3. You may need to do some legwork to get this working with core/python2


#3

Be aware also you may sometimes need to append your package’s path to the PYTHONPATH environment variable. You can do that like this in your plan.sh as needed:

do_setup_environment() {
  push_runtime_env PYTHONPATH "${pkg_prefix}/lib/python${python_major_version}/site-packages"
  return $?
}

This allows any package that depends on this one to inherit an additional layer of PYTHONPATH.