1

Similar to the system path, I want to offer some convenience in my code allowing a user to specify a file name that could be in one of a handful of paths.

Say I had two or more config paths

['~/.foo-config/', '/usr/local/myapp/foo-config/']

And my user wants to open bar, (AKA bar.baz)

  1. Is there a convenient build in way to let open('bar') or open('bar.baz') automatically search these paths for that file in LTR order of precedence? Eg, will temporary adjusting my sys.path to only be these directories do this for me?

  2. Else, how would you suggest implementing a PATH-like searching open-wrapper?

ThorSummoner
  • 16,657
  • 15
  • 135
  • 147

4 Answers4

2

As other people already mentioned: sys.path only affects the module search path, i.e. it's relevant for importing Python modules, but not at all for open().

I would suggest separating the logic for searching the paths in order of precedence and opening the file, because that way it's easier to test and read.

I would do something like this:

import os

PATHS = ['~/.foo-config/', '/usr/local/myapp/foo-config/']


def find_first(filename, paths):
    for directory in paths:
        full_path = os.path.join(directory, filename)
        if os.path.isfile(full_path):
            return full_path


def main():
    filename = 'file.txt'
    path = find_first(filename, PATHS)
    if path:
        with open(path) as f:
            print f
    else:
        print "File {} not found in any of the directories".format(filename)


if __name__ == '__main__':
    main()
Lukas Graf
  • 30,317
  • 8
  • 77
  • 92
  • You peeked my interest about testibility, is it possible to unit test a method that scans paths for a file? woudln't that require a unit test that prepares a set of real directories+files? Do you have any tips for unit testing this kind of thing cleanly? – ThorSummoner May 08 '15 at 18:14
  • 1
    Yes, having your test setup create actual directory structures is one way. There's not much to it actually, create the structure in `setUp()` and remove it again in `tearDown()`. A different approach would be to mock `os.path.isfile()` - you'd use something like [`unittest.mock.patch()`](https://docs.python.org/3/library/unittest.mock.html#unittest.mock.patch)` to replace `os.path.isfile()` with a mock that returns the values you tell it to, and allows you to make assertions on whether is has been called or not. – Lukas Graf May 08 '15 at 19:02
  • A third approach would be to factor out `os.path.isfile()` entirely from `find_first()`. So you'd pass a third argument `isfile_function` to `find_first()` - in production, that would just be the original `os.path.isfile`, but in tests it could be a no-op function that just records calls to it and returns a predefined value (this is not unlike the [Strategy Pattern](http://en.wikipedia.org/wiki/Strategy_pattern)). – Lukas Graf May 08 '15 at 19:09
1

open doesn't get into that kind of logic. If you want, write a wrapper function that uses os.path.join to join each member of sys.path to the parameter filename, and tries to open them in order, handling the error that occurs when no such file is found.

I'll add that, as another user stated, this is kind of a misuse of sys.path, but this function would work for any list of paths. Indeed, maybe the nicest option is to use the environment variables suggested by another user to specify a colon-delimited list of config directories, which you then parse and use within your search function.

jwilner
  • 6,348
  • 6
  • 35
  • 47
0

environmental variables

say your app is named foo ... in the readme tell the user to use the FOO_PATH environmental variable to specify the extra paths

then inside your app do something like

 for path in os.environ.get("FOO_PATH",".").split(";"):
     lookfor(os.path.join(path,"somefile.txt"))

you could wrap it into a generic function

def open_foo(fname):
   for path in os.environ.get("FOO_PATH",".").split(";"):
       path_to_test = os.path.join(path,"somefile.txt")
       if os.path.exists(path_to_test):
              return open(path_to_test)
   raise Exception("No File Found On FOOPATH")

then you could use it just like normal open

with open_foo("my_config.txt") as f:
     print f.read()
Joran Beasley
  • 110,522
  • 12
  • 160
  • 179
0

Extract from Python Standard Library documentation for open built-in function:

open(file, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None)

...file is either a string or bytes object giving the pathname (absolute or relative to the current working directory) of the file to be opened ...

Explicitely, open does not bring anything to automagically find a file : if path is not absolute, it is only searched in current directory.

So you will have to use a custom function or a custom class for that. For example:

class path_opener(object):
    def __init__(self, path = [.]):
        self.path = path
    def set(self, path):
        self.path = path
    def append(self, path):
        self.path.append(path)
    def extent(self, path):
        self.path.extend(path)
    def find(self, file):
        for folder in self.path:
            path = os.path.join(folder, file)
            if os.path.isfile(path):
                return path
        raise FileNotFoundError()
    def open(self, file, *args, **kwargs):
        return open(self.find(file), *args, **kwargs)

That means that a file opener will keep its own path, will be initialized by default with current path, will have methods to set, append to or extend its path, and will normaly raise a FileNotFoundError is a file is not found in any of the directories listed in its path.

Usage :

o = path_opener(['~/.foo-config/', '/usr/local/myapp/foo-config/'])
with o.open('foo') as fd:
    ...
Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252