projectile-direnv icon indicating copy to clipboard operation
projectile-direnv copied to clipboard

Export your projectile project's environment variables in .envrc

  • projectile-direnv.el

Have Emacs set environment variables defined in a project's .envrc.

  • Deprecation Notice

The newer [[https://github.com/wbolster/emacs-direnv][emacs-direnv]] project takes a slightly different approach, which solves some of the drawbacks of this solution. I encourage you to try it out.

  • Motivation

When working at the terminal, I use [[http://direnv.net/][direnv]] to export environment variables that alter the behavior of the [[http://12factor.net/][12 factor]] applications I write. direnv automatically exports the variables to the environment when you cd into a directory containing a .envrc file.

When launching a GUI instance of Emacs (not from the terminal), direnv never gets the chance to export your environment variables, however.

This package contains a command projectile-direnv-export-variables which will look for a .envrc file in the projectile-project-root.

It will then parse the .envrc file for exports and call setenv in the Emacs environment. This is useful, for instance, when launching processes from within Emacs (e.g. REPLs) that depend on the values in these variables.

  • Installation

This package is available on MELPA as projectile-direnv

[[https://melpa.org/#/projectile-direnv][file:https://melpa.org/packages/projectile-direnv-badge.svg]]

  • Dependencies
  • [[https://github.com/magnars/s.el][s]]
  • [[https://github.com/magnars/dash.el][dash]]
  • [[https://github.com/bbatsov/projectile][projectile]]
  • Usage

The easiest way to use this package is to invoke projectile-direnv-export-variables from a hook:

#+begin_src lisp

(add-hook 'projectile-mode-hook 'projectile-direnv-export-variables)

#+end_src

** Cautionary Note

You should only do this if you work on one project with a .envrc file at a time. This is because Emacs' environment is a global one, and projectile mode is per-buffer. It is easily conceivable to visit a file in one project and load envvars whose names clash with those in another project. This will cause a last-project-wins scenario that could lead to confusion and frustrated debugging.

There are two ways to address this concern.

  1. Explicitly invoke the command (instead of using a hook)
  2. Name your environment variables uniquely with a project prefix
  • Limitations / Known Issues
  • This package doesn't yet handle variable unloading
  • Ideally, the user should be prompted to allow a particular .envrc just as direnv does (and Emacs does when loading from .dir-locals.el)
  • License (GPL v3)

Copyright (C) 2016 Free Software Foundation, Inc.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.