<p>You could query Python for the working directory within the Snakefile, since evidently Snakemake changes the actual working directory of the process to the one specified by <code>--directory</code>.    For example, using a stub Snakefile with just these two lines:</p>

<pre><code>import os
print("Current working directory: " + os.getcwd())
</code></pre>

<p>And on the command line:</p>

<pre><code>$ snakemake --directory working-directory
Creating specified working directory working-directory.
Current working directory: /home/jesse/dev/snakemake-wd/working-directory
Building DAG of jobs...
Nothing to be done.
Complete log: /home/jesse/dev/snakemake-wd/working-directory/.snakemake/log/2019-08-02T142009.349338.snakemake.log
</code></pre>

CC BY-SA 4.0
2019-08-02T20:49:37.510Z
Thanks! This is the type of thing that seems super obvious after you've pointed it out, but wasn't obvious initially.
Daniel Standage
CC BY-SA 4.0
2019-08-02T21:47:43.143Z
No problem.  I wasn't sure myself if that was how they implemented `--directory` until I tried it out.  I guess it's an implementation detail but seems unlikely to me it'll change.
Jesse
CC BY-SA 4.0
2019-08-02T18:21:44.650Z
2019-08-02T18:21:44.650Z
Jesse
<p>Snakemake provides access to a <code>workflow</code> object within a Snakefile. This allows one to, for example, have dynamic programmatic access to the directory containing the Snakefile (via the <code>workflow.basedir</code> attribute). Is there a similar way to access the working directory that is specified on the command line using <code>--directory</code>?</p>

<p>Through a bit of exploration I was able to figure out that the <code>workflow</code> object has a <code>workdir()</code> method, but it appears this is used internally by Snakemake for registering working directories, not for access.</p>

<p><strong>UPDATE</strong>: It looks like the working directory is stored internally as the <code>_workdir</code> attribute of the <code>workflow</code> object. However, this attribute is unset (default value <code>None</code>) when I'm creating static/global objects in the Snakefile. Is it impossible to access the working directory prior to building the workflow DAG?</p>

<python><snakemake><workflow-management>
Access workdir defined on command line from within Snakefile
# Access workdir defined on command line from within Snakefile

(Asked by: username_0 on 2019-08-01)

Snakemake provides access to a `workflow` object within a Snakefile. This allows one to, for example, have dynamic programmatic access to the directory containing the Snakefile (via the `workflow.basedir` attribute). Is there a similar way to access the working directory that is specified on the command line using `--directory`?

Through a bit of exploration I was able to figure out that the `workflow` object has a `workdir()` method, but it appears this is used internally by Snakemake for registering working directories, not for access.

**UPDATE**: It looks like the working directory is stored internally as the `_workdir` attribute of the `workflow` object. However, this attribute is unset (default value `None`) when I'm creating static/global objects in the Snakefile. Is it impossible to access the working directory prior to building the workflow DAG?

**Tags:** python, snakemake, workflow-management

---

## 1 answers

### Answer by username_1 on 2019-08-02. Score: 2 | Accepted answer

You could query Python for the working directory within the Snakefile, since evidently Snakemake changes the actual working directory of the process to the one specified by --directory.    For example, using a stub Snakefile with just these two lines:
import os
print("Current working directory: " + os.getcwd())

And on the command line:
$ snakemake --directory working-directory
Creating specified working directory working-directory.
Current working directory: /home/jesse/dev/snakemake-wd/working-directory
Building DAG of jobs...
Nothing to be done.
Complete log: /home/jesse/dev/snakemake-wd/working-directory/.snakemake/log/2019-08-02T142009.349338.snakemake.log

> **Comments:**
> **username_0**: Thanks! This is the type of thing that seems super obvious after you've pointed it out, but wasn't obvious initially.  
> **username_1**: No problem.  I wasn't sure myself if that was how they implemented `--directory` until I tried it out.  I guess it's an implementation detail but seems unlikely to me it'll change.  

---

