dumpenv 2018.13.0

dumpenv: Dump values of the current Python environment

dumpenv: Dump values of the current Python environment

https://github.com/guettli/dumpenv

Why?

Sometimes source code works in one environment, but in a different environment it fails.

Same source code, but different results …. Hmm, there must be a differenence in the environment …. but what?

You can use this tool to dump a lot of values which influence the python interpreter.

Then you can use any diff tool (I like meld) to compare both environments.

At the moment these text files get created:

• PATH
• os
• os_environ
• pip_freeze
• platform
• site
• sys
• sys_path

I guess the above names do not need any explanation.

Above files get created in a temporary directory which roughly looks like this:

/tmp/dumpenv_{USER}@{HOST}--{VIRTUAL_ENV}_RANDOM

To make the diff easier to read $VIRTUAL_ENV and $HOME get replaced in the output.

Usage

Usage:

dumpenv [-o OUTPUT_DIRECTORY | --output-directory=OUTPUT_DIRECTORY]
dumpenv (-h | --help)

Options:

-o --output-directory OUTPUT_DIRECTORY Create text file in this directory.
                                     Or use environment variable DUMPENV_OUTPUT_DIRECTORY

Example

Example:

user1@host1> dumpenv
Dumped environment to directory OUT1

user2@host2> dumpenv
Dumped environment to directory OUT2

me@pc> scp -r user1@host1:/tmp/OUT1/ tmp/
me@pc> scp -r user2@host2:/tmp/OUT2/ tmp/
me@pc> meld tmp/OUT1 tmp/OUT2

… Ah! Now you see the difference :-)

API

Call it from Python like this:

out_dir = dumpenv.create_data_and_dump_it()

Install

Install from pypi:

pip install dumpenv

Use Cases

Use case 1: Your script works, but it does not, if called via unix cron. Run dumpenv via shell and via cron and compare the result.

Use case 2: Your code works via web (wsgi, django, …) but it fails if you call it on the shell.

Use case 3: Your code works in the development environment, but not on the production server.

Dream

In my case Python scripts run in different environments:

• called from PyCharm
• called from Shell
• called from Cron
• called from wsgi/Django.
• called from subprocess

My dream is that the environment from all above calls is equal.

Advertisment

• Created roughly according my own programming guidelines
• Uses subx instead of subprocess
• Uses my github commit, travis CI, bumpversion, Upload to pypi recipe

Feedback

Feedback is very welcome, please create an issue at github or write me an email.