1

I have the following code:

# script0.py
def main():
    p4 = p4python.P4.P4()
    p4.connect()
    print os.environ['P4CONFIG']
    print p4.p4config_file
    p4.disconnect()

which is being called via:

# script0_test.py
subprocess.check_call(['script0.py'])

and is outputting:

.p4config
noconfig

When script0.py is called from the command line or if subprocess.check_call(shell=True) is used, it outputs correct info:

.p4config
/home/nyap/proj/.p4config

Why does the p4 object not recognize the P4CONFIG setting when shell=False?

Noel Yap
  • 18,822
  • 21
  • 92
  • 144

2 Answers2

2

I ran into this same issue. It appears to be a bug in P4Python specific to Linux. The P4 class is being intialized with the current working directory set to '/' instead of the actual working directory. This then stops P4 from finding the .p4config file.

The following workaround fixed it for me:

  p4 = P4.P4(cwd=os.getcwd())
Jan
  • 41
  • 5
0

From a command-line, what does p4 set show for P4CONFIG? If it's not there, then you'll need to do p4 set P4CONFIG=".p4config" (on Windows or OS X). If your p4 set output already lists P4CONFIG then I don't know... If you're on Linux, the p4 set manpage says it will show the corresponding environment variables but you can't set them that way. In that case, I dunno.

Gordon Broom
  • 300
  • 1
  • 7
  • Yes. Why would the OS matter considering os.environ['P4CONFIG'] is saying that P4CONFIG is set? – Noel Yap Apr 27 '12 at 20:44
  • Because on the other OS's Perforce doesn't look at the environment variables first. It looks at it's own copies (in the registry on Windows, for example). That's why the OS matters. [edit: upon reading the manpage more closely, the environment variables are examined] – Gordon Broom Apr 27 '12 at 20:48