CODEWITHSUNDEEP
pythonbashenvironment-variables
kaligne
kaligne

Reputation: 3278

Organizing python project with setting environment

I develop Python tools. Each tool is part of a programming project, with source files and scripts to launch a program. Here the language is Python but could be any other.

src/
  package1/
    module1.py
  package2/
    module2.py
scripts/
  program1.py  # parses arguments; uses modules; starts workflow.
  program2.py  
  pylauncher.sh  # sets environment; deals with output; calls any specified python script.

Each Python script takes the user's input, parses the arguments provided, and starts a routine using the relevant Python modules. In the end the user just has to call the script this way:

$ cd path/scripts
$ python program1.py arg1 arg2

or, depending on the interpreter version,

$ cd path/scripts
$ path/to/the/right/python program1.py arg1 arg2

Currently I also have a bash script, pylauncher.sh, that I use to set Python path, Python libraries, redirecting of the input into a log, and such. So the user doesn't have to specify all this and has to launch the command:

$ cd path/scripts
$ ./pylauncher program1.py

This is convenient as it hides environment stuff from the user. But it seems to me that maybe the user should not be bothered with calling a launcher. So I am thinking of getting rid of the python scripts program{1,2}.py and renaming the pylauncher.sh into program{1,2}.sh. In doing so, the routine that was used in the former program{1,2}.py would be transferred into a module's main function, or simply moved there.

The project structure would look like:

src/
  package1/
    module1.py
    program1.py  # parses arguments; use python modules; starts the program workflow.
  package2/
    module2.py
    program2.py
scripts/
  program1.sh  # sources set_environment.sh; calls program1.py
  program2.sh  # sources set_environment.sh; calls program2.py
  set_environment.sh

Or letting the program{1,2}.py in the scripts folder:

src/
  package1/
    module1.py
  package2/
    module2.py
scripts/
  program1.py  # parses arguments; starts the program workflow.
  program1.sh  # sources set_environment.sh; calls program1.py
  program2.py
  program2.sh  # sources set_environment.sh; calls program2.py
  set_environment.sh

The user would in the end have to use the following command:

$ cd path/scripts
$ ./program1.sh

So I am currently using the first solution with the pylauncher bash script, and I am thinking about changing to the second solution. However I would like to know about other software devs' take, habits, practices. How would you do that? Do you see more convenient way, for the user, for the developer, if possible avoiding redundancies? Any advice and critics are welcome.

Upvotes: 1

Views: 242

Answers (1)

kalvatn
kalvatn

Reputation: 198

Have you considered packaging these tools as single file executables?

Here's a very basic example of what I mean using pyinstaller, I'm on a linux system, but the tool is cross platform and looks well documented.

requirements (python headers for building and PIP to install the package)

sudo apt-get install python-dev python-pip
sudo pip install pyinstaller

file to build

kalvatn@workstation|/tmp/python-executable » cat hello.py
#!/usr/bin/env python

if __name__ == '__main__':
    print 'hello world'

usage (the -F flag instructs pyinstaller to create a single file executable)

kalvatn@workstation|/tmp/python-executable » pyinstaller -F hello.py
kalvatn@workstation|/tmp/python-executable » ./dist/hello
hello world

doc

Upvotes: 1

Related Questions