text:
---
title: Habitat plan syntax reference
---

# Plan syntax guide

When defining a plan, there are several different settings, variables, and functions that you can use to set up specific installation and configuration details. Because plans are simply script files, you have a lot of flexibility in how you build and define the configuration of your application.

This syntax guide is divided into six parts:

- [Basic settings](#basic-settings)
- [Variables](#variables)
- [Callbacks](#callbacks)
- [Hooks](#hooks)
- [Runtime configuration settings](#runtime-configuration-settings)
- [Utility functions](#utility-functions)
- [Iterative development](#iterative-development)

## Basic settings
The following settings are defined at the beginning of your plan. They specify basic information about your plan such as name, version, and dependencies.

**pkg_name**
: Required. Sets the name of the package. This will be used along with `pkg_origin`, and `pkg_version` to define the fully-qualified package name, which determines where the package is installed to on disk, how it is referred to in package metadata, and so on. A `pkg_name` can contain upper and lowercase letters, numbers, dashes, and underscores.

  ~~~
  pkg_name=zlib
  ~~~

**pkg_origin**
: Required unless overridden by the `HAB_ORIGIN` environment variable. The origin is used to denote a particular upstream of a package. A `pkg_origin` can contain upper and lowercase letters, numbers, dashes, and underscores.

  ~~~
  pkg_origin=Habitat
  ~~~

**pkg_version**
: Optional (Required unless `pkg_version()` function is defined). Sets the version of the package.

  ~~~
  pkg_version=1.2.8
  ~~~

**pkg_maintainer**
: Optional. The name and email address of the package maintainer.

  ~~~
  pkg_maintainer="Your Name<EMAIL_ADDRESS>  ~~~

**pkg_license**
: Optional. An array of [valid software licenses](https://spdx.org/licenses/) that relate to this package.

  ~~~
  pkg_license=('Apache-2.0')
  ~~~

> Note: If your package has a custom license, use a string literal matching the title of the license. For example, you'll see `pkg_license=('Boost Software License')` for the `cmake` plan.

**pkg_source**
: Optional. A URL that specifies where to download an external source from. Any valid `wget` url will work. Typically, the relative path for the URL is partially constructed from the `pkg_name` and `pkg_version` values; however, this convention is not required.

  ~~~
  pkg_source=http://downloads.sourceforge.net/project/libpng/$pkg_name/${pkg_version}/${pkg_name}-${pkg_version}.tar.gz
  ~~~

**pkg_filename**
: Optional. The resulting filename for the download, typically constructed from the `pkg_name` and `pkg_version` values.

  ~~~
  pkg_filename=${pkg_name}-${pkg_version}.tar.gz
  ~~~

**pkg_shasum**
: Required if a valid URL is provided for `pkg_source` or unless **do_verify()** is overridden. The value for `pkg_shasum` is a sha-256 sum of the downloaded `pkg_source`. If you do not have the checksum, you can easily generate it by downloading the source and using the `sha256sum` or `gsha256sum` tools. Also, if you do not have **do_verify()** overridden, and you do not have the correct sha-256 sum, then the expected value will be shown in the build output of your package.

  ~~~
  pkg_shasum=36658cb768a54c1d4dec43c3116c27ed893e88b02ecfcb44f2166f9c0b7f2a0d
  ~~~

**pkg_deps**
: Optional. An array of package dependencies needed at runtime. You can refer to packages at three levels of specificity: origin/package, origin/package/version, or origin/package/version/release.

  ~~~
  pkg_deps=(core/glibc core/pcre core/openssl core/zlib)
  ~~~

**pkg\_build\_deps**
: Optional. An array of the package dependencies needed only at build time.

  ~~~
  pkg_build_deps=(core/gcc core/linux-headers)
  ~~~

**pkg\_lib\_dirs**
: Optional. An array of paths, relative to the final install of the software,
where libraries can be found. Used to populate `LD_FLAGS` and
`LD_RUN_PATH` for software that depends on your package.

  ~~~
  pkg_lib_dirs=(lib)
  ~~~

**pkg\_include\_dirs**
: Optional. An array of paths, relative to the final install of the software,
where headers can be found. Used to populate `CFLAGS` for software
that depends on your package.

  ~~~
  pkg_include_dirs=(include)
  ~~~

**pkg\_bin\_dirs**
: Optional. An array of paths, relative to the final install of the software,
where binaries can be found. Used to populate `PATH` for software
that depends on your package.

  ~~~
  pkg_bin_dirs=(bin)
  ~~~

**pkg\_pconfig\_dirs**
: Optional. An array of paths, relative to the final install of the
software, where pkg-config metadata (.pc files) can be found. Used to
populate `PKG_CONFIG_PATH` for software that depends on your package.

  ~~~
  pkg_pconfig_dirs=(lib/pkgconfig)
  ~~~

**pkg\_svc\_run**
: Optional. The command for the supervisor to execute when starting a service. You can omit this setting if your package is not intended to be run directly by a supervisor.

  ~~~
  pkg_svc_run="bin/haproxy -f $pkg_svc_config_path/haproxy.conf"
  ~~~

> Note: You should use a [run hook](#hooks) instead if you have complex start up behavior.

**pkg_exports**
: Optional. An [associative array](http://www.linuxjournal.com/content/bash-associative-arrays) representing configuration data which should be gossiped to peers. The keys in this array are used with `pkg_exposes` and for any consuming services that set `pkg_binds` or `pkg_binds_optional`. The values represent the TOML path to a value.

  ~~~
  pkg_exports=(
    [port]=server.port
    [host]=server.host
    [ssl-port]=ssl.port
  )
  ~~~

In this example, the corresponding default.toml file would have the following key/value pairs defined:

    [server]
    port = 80
    host = "www.example.com"

    [ssl]
    port = 443

**pkg_exposes**
: Optional. An array of `pkg_exports` keys containing default values for the ports that this package exposes. These values are used as sensible defaults for other tools, such as when exporting a package to a container format.

  ~~~
  pkg_exposes=(port ssl-port)
  ~~~

  > Note: In addition to specifying the keys you defined in `pkg_exports`, you **must** have a default.toml file indicating the port values to expose.

**pkg_binds**
: Optional. An associative array representing services which you depend on and the configuration keys that you expect the service to export (by their `pkg_exports`). These binds *must* be set for the supervisor to load the service. The loaded service will wait to run until its bind becomes available. If the bind does not contain the expected keys, the service will not start successfully.

  ~~~
  pkg_binds=(
    [database]="port host"
  )
  ~~~

**pkg\_binds\_optional**
: Optional. Same as `pkg_binds` but these represent optional services to connect to.

  ~~~
  pkg_binds_optional=(
    [storage]="port host"
  )
  ~~~

**pkg_interpreters**
: Optional. An array of interpreters used in [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) lines for scripts. Specify the subdirectory where the binary is relative to the package, for example, `bin/bash` or `libexec/neverland`, since binaries can be located in directories besides `bin`. This list of interpreters will be written to the metadata INTERPRETERS file, located inside a package, with their fully-qualified path.  Then these can be used with the fix_interpreter function. For more information on declaring shebangs in Habitat, see [Plan hooks](#hooks), and for more information on the fix_interpreter function, see [Plan utility functions](#plan-utility-functions).

  ~~~
  pkg_interpreters=(bin/bash)
  ~~~

**pkg\_svc\_user**
: Optional. The user to run the service as. The default is `hab`.

  ~~~
  pkg_svc_user=hab
  ~~~

**pkg\_svc\_group**
: Optional. The group to run the service as. The default is `hab`.

  ~~~
  pkg_svc_group=$pkg_svc_user
  ~~~

**pkg_description**
: Required for [core](https://github.com/habitat-sh/core-plans) plans, optional otherwise. A short description of the package. It can be a simple string, or you can create a multi-line description using markdown to provide a rich description of your package. {::comment} This description will be displayed on the Web app when users search for or browse to your package. {:/comment}

  ~~~
  pkg_description=$(cat << EOF
    # My package description
    This is the package for the foo library. It's pretty awesome.
    EOF
    )
  ~~~

> Note: Any special characters other than `#` will have to be escaped; otherwise, they could be interpreted by the hab-plan-build script when the package is built.

**pkg\_upstream\_url**
: Optional. An upstream project homepage or website URL.

  ~~~
  pkg_upstream_url=https://github.com/myrepo
  ~~~
---

## Variables
The following variables can be used in your plans to help get binaries and libraries to build and install in the correct locations in your package.

`$pkg_prefix`
: The absolute path for your package.

`$pkg_dirname`
: Set to `${pkg_name}-${pkg_version}` by default. If a .tar file extracts to a directory that's different from the filename, then you would need to override this value to match the directory name created during extraction.

`$pkg_svc_path`
: Where the running service is located. `$HAB_ROOT_PATH/svc/$pkg_name`

`$pkg_svc_data_path`
: Where the running service data is located. `$pkg_svc_path/data`

`$pkg_svc_files_path`
: Where the gossiped configuration files are located. `$pkg_svc_path/files`

`$pkg_svc_var_path`
: Where the running service variable data is located. `$pkg_svc_path/var`

`$pkg_svc_config_path`
: Where the running service configuration is located. `$pkg_svc_path/config`

`$pkg_svc_static_path`
: Where the running service static data is located. `$pkg_svc_path/static`

`$HAB_CACHE_SRC_PATH`
: The default path where source archives are downloaded, extracted, & compiled.

`$HAB_CACHE_ARTIFACT_PATH`
: The default download root path for packages.

`$HAB_PKG_PATH`
: The root path containing all locally installed packages.

`$PLAN_CONTEXT`
: The location on your local dev machine for the files in your plan directory.

`$CFLAGS`
: C compiler options.

`$LDFLAGS`
: C linker options.

`$PREFIX`
: Where to install the software; same as `$pkg_prefix`

`$LD_RUN_PATH`
: Where to find the binaries at run time.

---

## Callbacks
When defining your plan, you have the flexibility to override the default behavior of Habitat in each part of the package building stage through a series of callbacks. To define a callback, simply create a shell function of the same name in your plan.sh file and then write your script. If you do not want to use the default callback behavior, you must override the callback and `return 0` in the function definition.

These callbacks are listed in the order that they are called by the package build script.

**do_begin()**
: There is an empty default implementation of this callback. You can use it to execute any arbitrary commands before anything else happens. Note that at this phase of the build, no dependencies are resolved, the `$PATH` and environment is not set, and no external source has been downloaded. For a phase that is more completely set up, see the `do_before()` phase.

**do_before()**
: There is an empty default implementation of this callback. At this phase, the origin key has been checked for, all package dependencies have been resolved and downloaded, and the `$PATH` and environment are set.

**do_download()**
: The default implementation is that the software specified in `$pkg_source` is downloaded, checksum-verified, and placed in `$HAB_CACHE_SRC_PATH/$pkg_filename`, which resolves to a path like `/hab/cache/src/filename.tar.gz`. You should override this behavior if you need to change how your binary source is downloaded, if you are not downloading any source code at all, or if you are cloning from git. If you do clone a repo from git, you must override **do_verify()** to return 0.

**do_verify()**
: The default implementation tries to verify the checksum specified in the plan against the computed checksum after downloading the source tarball to disk. If the specified checksum doesn't match the computed checksum, then an error and a message specifying the mismatch will be printed to stderr. You should not need to override this behavior unless your package does not download any files.

**do_clean()**
: The default implementation removes the `HAB_CACHE_SRC_PATH/$pkg_dirname` folder in case there was a previously-built version of your package installed on disk. This ensures you start with a clean build environment.

**do_unpack()**
: The default implementation extracts your tarball source file into `HAB_CACHE_SRC_PATH`. The supported archive extensions are: .tar, .tar.bz2, .tar.gz, .tar.xz, .rar, .zip, .Z, .7z. If the file archive could not be found or has an unsupported extension, then a message will be printed to stderr with additional information.

**do_prepare()**
: There is no default implementation of this callback. At this point in the build process, the tarball source has been downloaded, unpacked, and the build environment variables have been set, so you can use this callback to perform any actions before the package starts building, such as exporting variables, adding symlinks, and so on.

**do_build()**
: The default implementation is to update the prefix path for the configure script to use `$pkg_prefix` and then run `make` to compile the downloaded source. This means the script in the default implementation does `./configure --prefix=$pkg_prefix && make`. You should override this behavior if you have additional configuration changes to make or other software to build and install as part of building your package.

**do_check()**
: The default implementation runs nothing during post-compile.  An example of a command you might use in this callback is `make test`. To use this callback, two conditions must be true. A) `do_check()` function has been declared, B) `DO_CHECK` environment variable exists and set to true, `env DO_CHECK=true`.

**do_install()**
: The default implementation is to run `make install` on the source files and place the compiled binaries or libraries in `HAB_CACHE_SRC_PATH/$pkg_dirname`, which resolves to a path like `/hab/cache/src/packagename-version/`. It uses this location because of **do_build()** using the `--prefix` option when calling the configure script. You should override this behavior if you need to perform custom installation steps, such as copying files from `HAB_CACHE_SRC_PATH` to specific directories in your package, or installing pre-built binaries into your package.

**do_strip()**
: The default implementation is to strip any binaries in `$pkg_prefix` of their debugging symbols. You should override this behavior if you want to change how the binaries are stripped, which additional binaries located in subdirectories might also need to be stripped, or whether you do not want the binaries stripped at all.

**do_after()**
: There is an empty default implementation of this callback. At this phase, the package has been built, installed, stripped, but before the package metadata is written and the artifact is created and signed.

**do_end()**
: There is an empty default implementation of this callback. This is called after the package artifact has been created. You can use this callback to remove any temporary files or perform other post-build clean-up actions.

---

## Hooks
Each plan can have a `hooks` subdirectory that specifies any of the hooks or asynchronous callbacks described in this section. Each hook is a script with a [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) defined at the top to specify the interpreter to be used.

**Important to note**
: You cannot block the thread in a hook unless it is in the `run` hook. Never call `hab` or `sleep` in a hook that is not the `run` hook.

**file_updated**
: File location: `<plan>/hooks/file_updated`
: This hook is run whenever a configuration file that is not related to a user or about the state of the service instances is updated.

**health_check**
: File location: `<plan>/hooks/health_check`
: This hook is run when the Habitat HTTP API receives a request at `/health`.

  The `health_check` script must return a valid exit code from the list below.

  - **0**- ok
  - **1**- warning
  - **2**- critical
  - **3**- unknown
  - any other code - failed health check with additional output taken from `health_check` stdout.

  A `health_check` hook can use the following as a template:

  ~~~ bash
  #!/bin/sh

  # default return code is 0
  rc=0
  program_that_returns_a_status
  case $? in
    0)
      rc=1 ;;
    3)
      rc=0 ;;
    4)
      rc=2 ;;
    *)
      rc=3 ;;
  esac

  exit $rc
  ~~~

**init**
: File location: `<plan>/hooks/init`

  This hook is run when a Habitat topology starts.

**reload**
: File location: `<plan>/hooks/reload`

For processes that can update their configuration without requiring a restart a `reload` hook can be written. This hook will execute instead of the default behaviour of restarting the process. `{{pkg.svc_pid_file}}` can be used to get a handle on the `PID` of the service.

**reconfigure**
: File location: `<plan>/hooks/reconfigure`

  This hook is run when service configuration information has changed through a set of Habitat services that are peers with each other. Before the `reconfigure` hook the config files are re-rendered and the process is either restarted or the `reload` hook is called if present.

**suitability**
: File location: `<plan>/hooks/suitability`

  The suitability hook allows a service to report a priority by which it should be elected leader. The hook is called when a new election is triggered and the last line it outputs to `stdout` should be a number parsable as a `u64`. In the event that a leader goes down and an election is started the service with the highest reported suitabilty will become the new leader.

**run**
: File location: `<plan>/hooks/run`

  This hook is run when one of the following conditions occur:

  - The main topology starts, after the `init` hook has been called.
  - When a package is updated, after the `init` hook has been called.
  - When the package config changes, after the `init` hook has been called, but before a `reconfigure` hook is called.

  You can use this hook in place of `$pkg_svc_run` when you need more complex behavior such as setting environment variables or command options that are based on dynamic configuration.

  Services run using this hook should do two things:

  - Redirect stderr to stdout (e.g. with `exec 2>&1` at the start of the hook)
  - Call the command to execute with `exec <command> <options>` rather than running the command directly. This ensures the command is executed in the same process and that the service will restart correctly on configuration changes.

  It is important to also consider what side effects the command to execute will have. For example, does the command spin off other processes in separate process groups? If so, they may not be cleaned up automatically when the system is reconfigured. In general, the command executed should behave in a manner similar to a daemon, and be able to clean up properly after itself when it receives a SIGTERM, and properly forward signals to other processes that it creates. For an even more specific example: let's say you are trying to start a node.js service. Instead of your command being `npm start`, you should use `node server.js` directly.

  A run hook can use the following as a template:

  ~~~ bash
  #!/bin/sh

  # redirect stderr
  exec 2>&1

  # Set some environment variables
  export MY_ENVIRONMENT_VARIABLE=1
  export MY_OTHER_ENVIRONMENT_VARIABLE=2

  # Run the command
  exec my_command --option {{cfg.option}} --option2 {{cfg.option2}}
  ~~~

**post-run**
: File location: `<plan>/hooks/post-run`

The post run hook will get executed after initial startup.

For many data services creation of specific users / roles or datastores is required. This needs to happen once the service has already started.

---

## Runtime configuration settings
The following configuration settings can be used during a Habitat service's lifecycle. This means that you can use these settings in any of the plan hooks, such as init, or run, and also in any templatized configuration file for your application or service.

These configuration settings are referenced using the [Handlebars.js](https://github.com/wycats/handlebars.js/) version of [mustache-style](https://mustache.github.io/mustache.5.html) tags. For an example on how these settings are used in plan hooks, see [Add Health Monitoring to a Plan](/tutorials/sample-app/mac/add-health-check-hook/) in the getting started tutorial.

### sys
These are service settings specified by Habitat and correspond to the network information of the running Habitat service.

**ip**
: The IP address of the running service.

**hostname**
: The hostname of the running service.

### pkg
These are package settings specified by Habitat and correspond to the the settings of the package when it was built and installed.

**origin**
: Denotes a particular upstream of a package. This value is pulled from the `pkg_origin` setting in a plan.

**name**
: The name of the package. This value is pulled from the `pkg_name` setting in a plan.

**version**
: The version of a package. This value is pulled from the `pkg_version` setting in a plan.

**release**
: The UTC datetime stamp when the package was built. This value is specified in _YYYYMMDDhhmmss_ format.

**ident**
: The fully-qualified identifier of a package that consists of origin/name/version/release.

**deps**
: An array of runtime dependencies for your package based on the pkg_deps setting in a plan.

**exposes**
: The port(s) to expose for an application or service. This value is pulled from the pkg_exposes setting in a plan.

**path**
: The location where the fully-qualified package is installed.

**svc_path**
: The root location of the source files for the Habitat service.

**svc\_config\_path**
: The location of any configuration files for the Habitat service.

**svc\_data\_path**
: The location of any data files for the Habitat service.

**svc\_files\_path**
: The location of any gossiped configuration files for the Habitat service.

**svc\_static\_path**
: The location of any static content for the Habitat service.

**svc\_var\_path**
: The location of any variable state data for the Habitat service.

**svc_user**
: The value of `pkg_svc_user` specified in a plan.

**svc_group**
: The value of `pkg_svc_group` specified in a plan.

**svc\_user\_default**
: The default user determined by the Habitat supervisor. `svc_user_default` will contain one of the following values, tested in order:

- `svc_user` if specified in the plan
- `hab` if the user exists
- the current user id

**svc\_group\_default**
: The default group determined by the Habitat supervisor. `svc_group_default` will contain one of the following values, tested in order:

- `svc_group` if specified in the plan
- `hab` if the group exists
- the effective group id

### cfg
These are settings defined in your templatized configuration file. The values for those settings are pulled from the `default.toml` file included in your package.

***

## Utility functions
The following helper functions can be useful in your plan to help you build your package correctly.

**attach()**
: Attaches your script to an interactive debugging session, which lets you check the state of variables, call arbitrary functions, and turn on higher levels of logging by using the `set -x` command and switch.

  To use attach, add `attach` to any callback or part of your plan.sh file and the debugging session with start up when hab-plan-build comes to that part in the file.

**download_file()**
: Downloads a file from a source URL to a local file and uses an optional
shasum to determine if an existing file can be used.

  If an existing file is present and the third argument is set with a shasum
digest, the file will be checked to see if it's valid. If so, the function
ends early and returns 0. Otherwise, the shasums do not match so the
file-on-disk is removed and a normal download proceeds as though no previous
file existed. This is designed to restart an interrupted download.

Any valid `wget` URL will work.

Downloads every time, even if the file exists locally:

~~~
download_file http://example.com/file.tar.gz file.tar.gz
~~~

Downloads if no local file is found:

~~~
download_file http://example.com/file.tar.gz file.tar.gz abc123...
~~~

File matches checksum: download is skipped, local file is used:

~~~
download_file http://example.com/file.tar.gz file.tar.gz abc123...
~~~

File doesn't match checksum: local file removed, download attempted:

~~~
download_file http://example.com/file.tar.gz file.tar.gz ohnoes...
~~~

Will return 0 if a file was downloaded or if a valid cached file was found.

**pkg\_path\_for()**
: Returns the path for a build or runtime package dependency on stdout from the list of dependencies referenced in `pkg_deps` or `pkg_build_deps`. This is useful if you need to install or reference specific dependencies from within a callback, such as `do_build()` or `do_install()`.

  Here's an example of how to use this function to retrieve the path to the perl binary in the core/perl package:

  ~~~
  _perl_path="$(pkg_path_for core/perl)/bin/perl"
  ~~~

**fix_interpreter()**
: Edits the `#!` shebang of the target file in-place. This is useful for changing hardcoded paths defined by your source files to the equivalent path in a Habitat package. You must include the required package that provides the expected path for the shebang in pkg_deps. This function performs a greedy match against the specified interpreter in the target file(s).

  To use this function in your plan, you must specify the following arguments:
    1. The target file or files
    2. The name of the package that contains the interpreter
    3. The relative directory and binary path to the interpreter

  For example, to replace all the files in `node_modules/.bin` that have `#!/usr/bin/env` with the coreutils path to `bin/env` (/hab/pkgs/core/coreutils/8.24/20160219013458/bin/env), you must quote the wildcard target as shown below.

  ~~~
  fix_interpreter "node_modules/.bin/*" core/coreutils bin/env
  ~~~

  For a single target, reference the file directly:

  ~~~
  fix_interpreter node_modules/.bin/concurrent core/coreutils bin/env
  ~~~

**pkg\_interpreter\_for()**
: Returns the path for the given package and interpreter by reading it from the INTERPRETERS metadata in the package. The directory of the interpreter needs to be specified, as an interpreter binary might live in `bin`, `sbin`, or `libexec`, depending on the software.

  The following shows how to call pkg_interpreter_for with the package and interpreter arguments specified.

  ~~~
  pkg_interpreter_for core/coreutils bin/env
  ~~~

  This function will return 0 if the specified package and interpreter were found, and 1 if the package could not be found or the interpreter is not specified for that package.

**pkg_version()**
: An optional way to determine the value for `$pkg_version`. The function must print the computed version string to standard output and will be called when the Plan author invokes the `update_pkg_version()` helper.

**update\_pkg\_version()**
: Updates the value for `$pkg_version` by calling a Plan author-provided `pkg_version()` function. This function must be explicitly called in a Plan in or after the `do_before()` build phase but before the `do_prepare()` build phase. The `$pkg_version` variable will be updated and any other relevant variables will be recomputed.

**abspath()**
: Return the absolute path for a path, which might be absolute or relative.

**exists()**
: Checks that the command exists. Returns 0 if it does, 1 if it does not.

**build_line()**
: Print a line of build output. Takes a string as its only argument.

~~~
build_line "Checksum verified - ${pkg_shasum}"
~~~

**warn()**
: Print a warning line on stderr. Takes a string as its only argument.

~~~
warn "Checksum failed"
~~~

**debug()**
: Prints a line only if the `$DEBUG` environment value is set to 1. The `debug` function takes a string as its only argument.

~~~
DEBUG=1
debug "Only if things are set"
~~~

**exit_with()**
: Exits the program with an error message and a status code.

~~~
exit_with "Something bad happened" 55
~~~

**trim()**
: Trims leading and trailing whitespace characters from a bash variable.

**record()**
: Takes a session name and command to run as arguments function appends a timestamp to the log file. Alternative to piping build through tee.

~~~
Usage: record <SESSION> [CMD [ARG ...]]
record mysoftware build /src/mysoftware
~~~

---

## Iterative Development
To assist in creating new packages, or modifying existing ones, the supervisor
has an option to allow you to use the configuration directly from a specific
directory, rather than the one it includes in the compiled artifact. This can
significantly shorten the cycle time when working on configuration and hooks.

First, build the plan as you normally would. Second, when you start the
supervisor, pass the name of the directory with your plan inside it:

```
$ hab start core/redis --config-from /src
```

This would take the configuration and hooks from /src, rather than from the
package you have previously built. When the configuration is as you want it,
do a final rebuild of the package.

repository: blakestier/habitat

repo_name: blakestier/habitat


text:
# interpPES
Interpolate between stationary points on the potential energy surface

This package contains some small and easy utilities for interpolating between
stationary points on potential energy surfaces by methods like the Nudged
Elastic Band method, based on the Atomic Simulation Environment for the core
operations.

license: MIT

repository: tschijnmo/interpPES

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: tschijnmo/interpPES


text:
[![Build status](https://ci.appveyor.com/api/projects/status/va25mgec2bfvsm6w?svg=true)](https://ci.appveyor.com/project/Talento90/repository-mongodb-net)

# Repository.MongoDb.Net
A simple generic MongoDb repository (Driver 2.0.1) for C# language. This repository contains the basic CRUD methods (Get, Delete, Update, Insert, GetAll, Pagination).

**Features**
 - Completely Asynchronous
 - Document Version (Consistency)
 - Integration Tests
 - Exception Handling

PS: To run the tests it's necessary to configure the connectionString in folder *"Core.Repository.MongoDb.Tests"*.


text:
---
title: Additional 3D Concepts
module: 8
jotted: false
---

# Additional 3D Concepts

  <button class="tablinks active" onclick="openTab(event, 'Overview')">Overview</button>
  <button class="tablinks" onclick="openTab(event, 'custom')">Custom</button>
  <button class="tablinks" onclick="openTab(event, 'textures')">Textures</button>
  <button class="tablinks" onclick="openTab(event, 'text')">Text</button>
  <button class="tablinks" onclick="openTab(event, 'webgltext')">WebGL text</button>
  <button class="tablinks" onclick="openTab(event, 'lights')">Lights</button>
  <button class="tablinks" onclick="openTab(event, 'materials')">Materials</button>

### 3D Primitives Shapes

There are 7 different 3D geometry primitives in p5.js.

* box()
* plane()
* sphere()
* ellipsoid()
* cone()
* cylinder()
* torus()

Each of these primitives take only size parameters, not position. For example:

```js
box(10,20,30); //draws a box of width: 10, height: 20, and depth: 30
cone(40, 100, 100);//draws a cone with radius: 40, height: 100, and a detail of 100
```

You may be saying, “Hey now, what’s this detail you speak of?!” In webgl mode, the user can specify how smooth the curves and lines should be drawn. Larger detail numbers create smoother curves, however at the expense of the graphics renderer. Generally, leaving the default detail is sufficient when drawing primitives:

```js
cone(40,100);//draws a cone with radius: 40, height: 100, and a default detail: 24
```

One important difference between drawing primitives in 3d and drawing primitives in 2d is that 3d primitives take size parameters, but not position. To reposition 3D primitives, simply call **translate(x,y,z);** as per the Translation section from before.

### Custom shapes & 2D drawing in WEBGL

In the introduction, we mentioned that WEBGL mode supports both 2D and 3D drawing. While WEBGL is optimized for 3D, you don’t necessarily have to always draw in 3D. For 2D drawing, there are the point(), line(), triangle() and quad() functions. For example,

```js
for(let i = 0; i < 500; i+=100){
  push();
  fill(i * 0.1, 100, 100);

  //line
  translate(0, 100, 0);
  line(-100, 0, i, 100, 0, i);

  //triangles
  translate(0, 100, 0);
  triangle(
    0, sin( i + frameCount * 0.1) * 10, i,
    60, 60, i,
    -60, 60, i);

  //quad
  translate(0, 200, 0);
  quad(
    -100, i, 0,
    100, i, 0,
    -100, 100, i,
    100, 100, i
    );
  pop();
}
```

If we look more closely at the quad() function, you’ll notice there are 12 parameters- 4 groups of 3 (x,y,z). Even though we are drawing a 2-dimensional shape, we still need to use the z-coordinate for each vertex.

Another way of drawing custom shapes in WEBGL mode is to use beginShape() and endShape(). This works exactly the same in 2d mode as it does in WEBGL, except in WEBGL, vertices receive x, y, and z as location coordinates.

```js
beginShape();
vertex(100,23,-100);
vertex(200,23,-50);
vertex(150, 45,-100);
endShape();
```

### Textures

At the time of this writing, p5.js supports video, image, and offscreen 2d renderers as textures in WEBGL mode.  For example, if you want a static image to “texture” a box, you would write something like this:

```js
let img;
function preload(){
  img = loadImage(“path/to/img.jpg”);
}
function setup(){
  createCanvas(500,500,WEBGL);
}
function draw(){
  background(255);
  texture(img);
  box(45);
}
```

Loading images for texturing inside the preload() method is generally a best practice, but it is especially helpful when working with video since video files are generally larger than static images and can take therefore extra time to load.

To texture a beginShape() graphic you will need to pass in u,v coordinates. These coordinates map to the texture being applied. With textureMode(NORMAL) we tell p5 to normalize these values between 0 and 1. See the textureMode() reference for more info.

Below is an example:

```js

let img;
function setup() {
  createCanvas(windowWidth, windowHeight, WEBGL);
  img = loadImage("path/to/img.jpg");
  textureMode(NORMAL);
}

function draw() {
  background(200);
  texture(img)

  // Assuming img has 100 pixels width and height
  beginShape();
  vertex(0, 0, 0, 0, 0);
  vertex(100, 0, 0, 1, 0);
  vertex(100, 100, 0, 1, 1);
  vertex(0, 100, 0, 0, 1);
  endShape(CLOSE);
}
```

### Text

To work with text in webgl mode, you have two options: use the 2d p5.js API to render to an offscreen image, or use the native webgl text() method. There are advantages & disadvantages to both which are discussed below:

#### Offscreen Renderer
You can draw your text to an offscreen renderer first, and then use it as a texture.

#### Advantages:

You can use the same fonts available to the 2d p5.js API, including the browser's built-in fonts (eg, 'mono', 'sans', etc...).
You can use stroke() to draw an outline around the glyphs.
The performance may be better, especially if you are able to render your text only once in setup() and reuse that texture in your draw() function.
Disadvantages:

The fidelity of the text may not be as high as with the text() method due to pixellation when zooming or inaccuracies in anti-aliasing when tilting the text image.
Here is an example of using an offscreen renderer to draw text:

```js
let pg;
function setup(){
  createCanvas(100, 100, WEBGL);
  pg = createGraphics(256,256);
}
function draw(){
  background(0);
  pg.background(255);
  pg.text('hello world!', 50, 50);
  //pass graphics as texture
  texture(pg);
  plane(100);
}
```

### webgl text()

The webgl version of the text() method works very similarly to the 2d version. However there are a few differences:

**Disadvantages:**

You can only use use opentype/truetype fonts loaded in your preload() function using the loadFont() method. You must either place those font files in a location accessible from your sketch, or use a CORS-compatible webl URL.
stroke() is not currently supported.
Advantages:

The fidelity of the rendered text should be better, especially when zooming & tilting.
The performance may be better, especially if the text changes regularly and you are unable to cache the offscreen image used in the previous method.
Here is an example of loading an opentype font and using it to draw text with the webgl text() method:

```js
let myFont;
function preload() {
  myFont = loadFont('assets/AvenirNextLTPro-Demi.otf');
}

function setup() {
  fill('#ED225D');
  textFont(myFont);
  textSize(36);
  text('p5*js', 10, 50);
}
```

### Lights

The last big inclusion in WEBGL mode is lights. Lighting is a simple but powerful way to provide depth and realism to p5.js sketches. At the time of this writing there are 3 types of light functions in p5.js:

* ambientLight();
* directionalLight();
*pointLight();

```js
ambientLight(255,0,0); //even red light across our objects
box(25);
```

**ambientLight()** is the simplest of the three functions, and it provides even (omnidirectional) ambient lighting to objects drawn afterward. It takes a p5.Color or r,g,b numerical values as parameters.

```js
directionalLight(r, g, b, x, y, z):
let dirY = (mouseY / height - 0.5) *2;
let dirX = (mouseX / width - 0.5) *2;
directionalLight(250, 250, 250, dirX, -dirY, 0.25);
ambientMaterial(250);
sphere(50, 64);
```

**directionalLight** rays shine in a given direction, but they do not have a specific point of origin, and therefore cannot be positioned closer or farther away from a geometry. The directionalLight vector can also be considered the angle in which light hits the geometry. Therefore, a negative y-value will light a given geometry from below.

**pointLight()**: On the other hand, pointLight takes a color and a location as parameters. The major difference between directionalLight and pointLight is pointLight shines from a specific point of origin, and therefore reflects differently when it is farther vs. nearer the object.

### Materials

In the real world, light reflects off objects differently, depending on their angle of reflection as well as the object's’ material. At the time of this writing there are four types of materials in p5.js:

* normalMaterial()
* ambientMaterial()
* specularMaterial()

**normalMaterial()** does not take any parameters, it automatically maps a geometry’s normal vectors to RGB colors. For more information on geometry normals, we find this Wikipedia entry to be pretty helpful.

(At one time, there was also a basicMaterial() which fills the following geometry with a color, but is not affected by any of the light functions(). However, due to it being the same as fill(), it was removed and the function fill() can be used with WEBGL for the "basic material" functionality.)

**ambientMaterial()** is like fill(), however the total color is affected by light functions that precede it.

**specularMaterial()** is the most “realistic” of the four materials. Specular material is a technical way of describing a material that reflects light in a single direction. This effect is often perceived in the real world as being glassy, water-like, or perhaps in the above example, a billiards ball. For example:

```js
pointLight(255, 255, 255, mouseX, mouseY, 0);
specularMaterial(250, 0, 0);
sphere(50, 64);
```

branch_name: refs/heads/main


text:
# [Flask Paper Kit](https://appseed.us/apps/flask-apps/flask-paper-kit)

**Open-Source Web App** coded in **[Flask Framework](https://palletsprojects.com/p/flask/)** - Provided by **AppSeed** [Web App Generator](https://appseed.us/app-generator).

### App Features:

- SQLite database
- SQLAlchemy ORM
- Session-Based authentication flow (login, register)
- UI Kit: [Paper Kit](https://github.com/app-generator/fork-paper-kit-html) by **Creative-Tim**

## Build from sources

```bash
$ # Clone the sources
$ git clone https://github.com/app-generator/flask-paper-kit.git
$ cd flask-paper-kit
$
$ # Virtualenv modules installation (Unix based systems)
$ virtualenv --no-site-packages env
$ source env/bin/activate
$
$ # Virtualenv modules installation (Windows based systems)
$ # virtualenv --no-site-packages env
$ # .\env\Scripts\activate
$
$ # Install requirements
$ pip3 install -r requirements.txt
$
$ # Set the FLASK_APP environment variable
$ (Unix/Mac) export FLASK_APP=run.py
$ (Windows) set FLASK_APP=run.py
$ (Powershell) $env:FLASK_APP = ".\run.py"
$
$ # Set up the DEBUG environment
$ # (Unix/Mac) export FLASK_ENV=development
$ # (Windows) set FLASK_ENV=development
$ # (Powershell) $env:FLASK_ENV = "development"
$
$ # Run the application
$ # --host=<IP_ADDRESS> - expose the app on all network interfaces (default <IP_ADDRESS>)
$ # --port=5000    - specify the app port (default 5000)
$ flask run --host=<IP_ADDRESS> --port=5000
$
$ # Access the app in browser: http://<IP_ADDRESS>:5000/
```

## Support

- Free support via eMail < [support @ appseed.us](https://appseed.us/support) > and **Github** issues tracker
- 24/7 Live Support via [Discord](https://discord.gg/fZC6hup) for paid plans and commercial products.

## Credits & Links

- [Flask Paper Kit](https://appseed.us/apps/flask-apps/flask-paper-kit) - Product page
- [Flask Framework](https://www.palletsprojects.com/p/flask/) - The offcial website
- [Flask Boilerplate - Open-Source Apps built with automation tools](https://dev.to/sm0ke/flask-boilerplate-open-source-apps-built-with-automation-tools-4925) - a popular article published on **Dev.to** platform

## License

@MIT

---
[Flask Paper Kit](https://appseed.us/apps/flask-apps/flask-paper-kit) - Provided by **AppSeed** [Web App Generator](https://appseed.us/app-generator).

repository: app-generator/flask-paper-kit

repo_name: app-generator/flask-paper-kit


text:
# Writing a Feathers REST Client

We already have a Feathers REST API server from the previous example.
Let's write a Javascript frontend for it.

## Working example

| Server source code: https://github.com/eddyystop/feathers-an-introduction/blob/master/examples/02/b/3.js

| Client HTML code: https://github.com/eddyystop/feathers-an-introduction/blob/master/examples/02/common/public/rest.html

| Client source code: https://github.com/eddyystop/feathers-an-introduction/blob/master/examples/02/common/public/feathers-app.js

| Start the server: `node ./examples/02/b/3`

| Point the browser at: `//localhost:3030/rest.html`

## Writing a server for Feathers client REST calls

Our frontend will communicate with the server using the server's REST API.
So we have to tell the server to allow REST calls from a Feathers client.

```javascript
const rest = require('feathers-rest'); // added

const app = httpServerConfig()
  .configure(rest()) // added
  .configure(services)
  .configure(middleware);
```

That's all!

## Writing the frontend HTML

We'll soon see most of the frontend doesn't care if we're communicating with the server
using REST or websockets.
To keep things DRY, we are isolating in this HTML the code which is unique to REST.

```HTML
<html>
<head>
  <title>Feathers REST client</title>
  <style>
    body {
      font-family: 'Helvetica Neue', 'Helvetica', 'Arial', 'sans-serif';
      font-weight: 400;
      font-size: 16px;
      color: #333;
    }
  </style>
</head>
<body>
<h1>Feathers guide</h1>
<h2>Example 02.b.2 - Feathers REST client</h2>
<br />
Open console to see results of <strong>feathers-rest</strong> calls.
<script type="text/javascript" src="//cdnjs.cloudflare.com/ajax/libs/core-js/2.1.4/core.min.js"></script>
<script<EMAIL_ADDRESS><script src="/serverUrl.js"></script>
<script>
  const app = feathers()
      .configure(feathers.rest(serverUrl).fetch(fetch))
</script>
<script src="/feathers-app.js"></script>
</body>
</html>
```

- `//cdnjs.cloudflare.com/ajax/libs/core-js/2.1.4/core.min.js` loads a pollyfill for `fetch` if required.
-<EMAIL_ADDRESS>loads Feathers client code.
- `src="/serverUrl.js"` loads the URL of the server for the frontend.
The default is `var serverUrl = 'http://localhost:3030';`.
- `const app = feathers()` instantiates a Feathers client.
- `.configure(feathers.rest(serverUrl).fetch(fetch))` configures the client to use REST
when communicating with the server.
It points to the server,
and passes the `fetch` instruction as the interface for fetching resources.
- `src="/feathers-app.js"` loads the main application.

## Writing the Feathers frontend

Writing the HTML was actually the hard part.
The rest of the application is just a copy of what we used in
[Writing a Database Connector](./database-connector.md)!

```javascript

const users = app.service('/users');

Promise.all([
  users.create({ email<EMAIL_ADDRESS>password: '11111', role: 'admin' }),
  users.create({ email<EMAIL_ADDRESS>password: '22222', role: 'user' }),
  users.create({ email<EMAIL_ADDRESS>password: '33333', role: 'user' }),
  users.create({ email<EMAIL_ADDRESS>password: '44444', role: 'user' }),
])
  .then(results => {
    console.log('created Jane Doe item\n', results[0]);
    console.log('created John Doe item\n', results[1]);
    console.log('created Judy Doe item\n', results[2]);
    console.log('created Jack Doe item\n', results[3]);

    const jackId = results[3]._id;
    return users.remove(jackId)
      .then(results => console.log('deleted Jack Doe item\n', results));
  })
  .then(() => {
    return users.find()
      .then(results => {
        console.log('find all items\n', results);
        console.log((results || []).length, 'items returned.');
      })
  })
  .catch(err => console.log(err));
```

The results in the console window of the browser are the same as they were
running the database connector.

```text`
created Jane Doe item
 Object {email<EMAIL_ADDRESS>password: "11111", role: "admin", _id: "8zQ7mXay3XqiqP35"}
created John Doe item
 Object {email<EMAIL_ADDRESS>password: "22222", role: "user", _id: "l9dOTxh0xk1h94gh"}
created Judy Doe item
 Object {email<EMAIL_ADDRESS>password: "33333", role: "user", _id: "3BeFPGkduhM6mlwM"}
created Jack Doe item
 Object {email<EMAIL_ADDRESS>password: "44444", role: "user", _id: "7b0N4w9jmA328yhq"}
deleted Jack Doe item
 Object {email<EMAIL_ADDRESS>password: "44444", role: "user", _id: "7b0N4w9jmA328yhq"}
find all items
 [Object, Object, Object]
   0: Object
     _id: "3BeFPGkduhM6mlwM"
     email<EMAIL_ADDRESS>     password: "33333"
     role: "user"
   1: Object
     _id: "8zQ7mXay3XqiqP35"
     email<EMAIL_ADDRESS>     password: "11111"
     role: "admin"
   2: Object
     _id: "l9dOTxh0xk1h94gh"
     email<EMAIL_ADDRESS>     password: "22222"
     role: "user"
  length: 3
3 "items returned."
```

> **Feathers "ah-ha" moment.**
We can run **exactly** the same code on the frontend as on the server.
We can code the frontend as if the database was sitting on the frontend.
This makes frontend development significantly simpler.

repository: marshallswain/feathers-an-introduction

repo_name: marshallswain/feathers-an-introduction


text:
# The event of three in the morning
by Marlen Lopez

## #0
It's year 2123, it has been 10 years since humanity has suffered from spaceship attacks from an unknown enemy. They have launch several kind of attacks, starting with internet, no radio signals, water and food is scarce. They have been taking Earth to eliminate humanity, but nobody have seen who they are.

The military, desperate to defeat this enemy, has started recruiting people from 14 to 18 years, to train and stop the strangers. You have been selected for this.

Once you start, you get to choose a superability provided by a technological chip.

## Actions
* [Time traveling](#1)
* [Teleportation](#2)
* [Shapeshifting](#3)

## #1
Once you obtained this power, the first thing that comes into you mind is to travel to the past to see how everything started.

## Actions
* [Continue](#4)

## #2
During your training, you have noticed a suspicious goverment officer and you have decided to spy on him by teleporting to his office.

## Actions
* [Continue](#4)

## #3
With your new power, you change your shape to resemble one of the goverment officers to gather some information.

## Actions
* [Continue](#4)

## #4
You discovered that two military officials have brought the unknown enemys without anybody noticing. They have been manipulating the world and they wanted to take control of the whole military to dominate Earth.

## Actions
* [You decided to stay on the military to be part of world takeover](#5)
* [You try to warn the rest of the recruits to escape together](#6)
* [You create a group to comfront the agents an the enemies](#7)

## #5
The enemies didn't intend to keep you or the military. They have enslaved the whole military and eliminated the rest of the humanity while their species takes over.

## #6
Only a few believe in you, and the rest laughs about you. They have warn the military officers, but the officers decided to lock up everyone to avoid somebody else knowing the truth. You and four other recruits manage to stay hidden.

## Actions
* [Continue](#8)

## #7
Only five recruits have believed in you and secretly all have started to prepare a plan to face them.

## Actions
* [Continue](#9)

## #8

You stay hidden for two days, as you cannot escape thanks to all the guards around. The military base where you are, is misteriously attacked and you consider this a perfect oportunity to escape, which you managed to do. While escaping, you realized that the attack was done by the unknown enemies. Them, once they noticed that the military is not responding decided to take the world for their own. Now you and the rest of the recruits with you are the only ones capable to confront the situation. You know you don't enough training but Earth is being invaded.

## Actions
* [You think is the end of the world and decided to surrender, let them take Earth.](#10)
* [Confront the enemies without knowing who they are. Use your powers without thinking on the consequences they might have.](#11)
* [Try to face up the enemies and manage to get a deal for Earth](#12)

## #9

After spending days working on your plan and with enough care to not raise any suspicion, the military base where you're staying have received and attack. The attack has been from the unknown enemy. Them noticing not receiving any response from the military decided it's time to take over the world. Now you and your team are the ones facing the situation. You don't have enough training, but your planet is being invaded.

## Actions
* [You think is the end of the world and decided to surrender, let them take Earth.](#10)
* [Confront the enemies without knowing who they are. Use your powers without thinking on the consequences they might have.](#11)
* [Try to face up the enemies and manage to get a deal for Earth](#12)

## #10
The enemies have won the war. They have enslaved the whole military and eliminated the rest of the humanity.

## #11
You fight along with the military to eliminate the enemies, but they are just more everytime. Once you noticed you're not winning you decided to take refuge and think on something else. Your team, the military and the rest of the world depends on it.

## Actions
* [Continue](#13)

## #12
You manage to get into one of their space ships. Now you know who they are. Nobody knows about you and you remember nothing since then.

## #13
There are very few people left and the life condition is not good. The people decide that the young military takes charge and you are in charge to guide them. What will you do?

## Actions
* [You see no choice and decided to stay hidden](#14)
* [You move to another country to ally with their military and reinforce them to defeat the enemies.](#15)
* [Search for military spaceships to escape to another planet](#16)

## #14
You stay hidden until the enemies find you. You'll know if they decided to eliminate you or enslave you.

## #15
The enemy attacks have defeated and taken every country. There is no way out and it the end for you.

## #16
You manage find some spaceships an escape. Everybody is out from Earth now. On space, stranded, alone. There are no planets anymore. What has happened? Are there more enemies? What's left now?

gha_language: C#


text:
# ci-test

[![wemake.services](https://img.shields.io/badge/%20-wemake.services-green.svg?label=%20&logo=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAALGPC%2FxhBQAAAAFzUkdCAK7OHOkAAAAbUExURQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP%2F%2F%2F5TvxDIAAAAIdFJOUwAjRA8xXANAL%2Bv0SAAAADNJREFUGNNjYCAIOJjRBdBFWMkVQeGzcHAwksJnAPPZGOGAASzPzAEHEGVsLExQwE7YswCb7AFZSF3bbAAAAABJRU5ErkJggg%3D%3D)](https://wemake.services)
[![Build Status](https://travis-ci.com/meklon/ci-test.svg?branch=master)](https://travis-ci.com/meklon/ci-test)
[![Coverage](https://coveralls.io/repos/github/meklon/ci-test/badge.svg?branch=master)](https://coveralls.io/github/meklon/ci-test?branch=master)
[![Python Version](https://img.shields.io/pypi/pyversions/ci-test.svg)](https://pypi.org/project/ci-test/)
[![wemake-python-styleguide](https://img.shields.io/badge/style-wemake-000000.svg)](https://github.com/wemake-services/wemake-python-styleguide)

Just a simple test of CI

## Features

- Fully typed with annotations and checked with mypy, [PEP561 compatible](https://www.python.org/dev/peps/pep-0561/)
- Add yours!

## Installation

```bash
pip install ci-test
```

## Example

Showcase how your project can be used:

```python
from ci_test.example import some_function

print(some_function(3, 4))
# => 7
```

## License

[MIT](https://github.com/meklon/ci-test/blob/master/LICENSE)

## Credits

This project was generated with [`wemake-python-package`](https://github.com/wemake-services/wemake-python-package). Current template version is: [aa39fa83ce92d9572a57fe74ed14464ffb77d9b4](https://github.com/wemake-services/wemake-python-package/tree/aa39fa83ce92d9572a57fe74ed14464ffb77d9b4). See what is [updated](https://github.com/wemake-services/wemake-python-package/compare/aa39fa83ce92d9572a57fe74ed14464ffb77d9b4...master) since then.

repository: meklon/ci-test

repo_name: meklon/ci-test


text:
Eclipse UI Preferences
======================

Some Java editor preferences modified in order to be more clear when reading the code

Requirements
------------

* Eclipse Color Themes (http://eclipsecolorthemes.org)
* Eclipse UI Themes (https://github.com/rogerdudler/eclipse-ui-themes)

Installation
------------

* Start Eclipse and go to *Preferences > General > Appearance* and choose *MoonRise (standalone)* (optional)
* Go to *Preferences > General > Appearance > Color Theme* and choose *Obsidian*
* Copy all files to {workspace directory} ({workspace directory}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs)

repository: rpinzon/eclipse-ui-prefs

repo_name: rpinzon/eclipse-ui-prefs