File (s) not on client

Question

I'm getting a really weird problem with P4Python since I started implementing workspace awareness.

The situation is as follows:

I have a "P4Commands" module which inherits P4 and connects in the __init__()

Then, I have respectively the following classes:

• P4User
• P4Workspace
• P4Changelist

The P4Commands module inherits P4 and calls its parent's "run" method while also injection some custom caching I've implemented to speed up large numbers of calls. The run method gets called as such:

result = super(P4Commands, self).run(*args, **kwargs)

This then gets logged and returned.

When I call an operation on a file, I go through P4User first to figure out which workspace the file is in. Then, I do the following on the workspace instance that's found to match:

def run(self, *args, **kwargs):
    # run whatever commands have to be run, with client temporarily set 
    # to this instance's client setting.
    with self.FUNCS.saved_context(client=self.client) as _:
        return self.FUNCS.run(*args, **kwargs)

Where FUNCS is a P4Commands module instance.

The problem I'm getting is that for a file that returns info when I call fstat on it, I get "file (s) not on client" as an error, only when I call the "edit" command. Every other command (add, fstat, where, etc.) seems to work fine. This happens ONLY on the edit command.

The weird thing is, I don't get the error when I run the method with the exact same arguments, but outside of the workspace context manager (on the P4User module directly).

It gets weirder: I tried disabling the context manager, still no joy.

One more thing to add to the weirdness, when reading this, you might be thinking "oh, the client is not being set properly". I tried logging the client workspace, and it's correctly being set and unset. Like I said, all other commands work, just not edit.

The only scenario that remained is that multiple P4 module instances' connections were interfering. I tried making P4Commands a static global with only one instance shared across every module. That didn't end up working either.

I've tried various approaches, but I'm a bit stuck at this point. Does anyone have a clue as to how to solve this?

Guadalupeguadeloupe

Answer 1

After a lot of searching I managed to solve this:

I was instancing the P4 connection as a class member, which was messing with the instance as every P4Workspace instance was sharing the same connection and trying to take ownership. Despite most commands working, this seems to have been messing with the connection as causing the problem listed above.

The way I ended up solving this was to make the P4-inherited class instance an instance variable of the P4Workspace class. Before, it was a class member.

So the structure that ended up working is:

• P4User - class member called FUNCS which instances a connection for non-workspace specific calls. Contains multiple P4Workspace instances.
• P4Workspace - instance variable called "connection" which creates a workspace-specific connection to perforce on instance.

Guadalupeguadeloupe