I think it does… they went from VS2010 to VS2012? no?
Hey
I’m trying to test our tools on Maya 2015 right now, the problem I’m having is that it appears the P4 plugin / P4API.pyd isnt supported in 2015 yet ( I’m going from 2013 > 15 - so no idea if this is working in 14 either. )
Anyone got any ideas?
Cheers
Joe
Hmmm
this version imports & I’ve got communication with Perforce ( yay ) - Doing complete test of all our tools now 
http://www.youcandoitvfx.com/p4python-for-3ds-max-2015-maya-2015/
If i understand “you can do it!” correctly - am i right in saying that Perforce need to release a new version of their API for Python 2.7?
{ Maya broke binary compatibility with previous versions, making the P4API for Python 2.7 no longer compatible with Mayas Python 2.7? }
P4Python just uses the C++ project under the hood. Their expectation is that you will download the source and compile it for the flavor of Python you are using. Yeah, they could make it easier, but they do “release” it.
Cool thanks for the clarification
something to look out for if you plan on upgrading to 2015.
PySide 1.2 has a crash bug related to QSelectionModels.
Here’s a nasty 2015 but to watch out for:
cmds.ls now crashes on bad characters in an object name, which is a new behavior that can break lots of old scripts.
It’s a good thing no one uses the ls command…
Or you could write your own Python wrapper that calls the standard P4 commands via subprocess module. The P4 command is well documented and seems stable over time.
def __callCommand(self, args):
‘’’
executes external system command using subprocess
This is essentially like using os.system, but allows you to use subprocess.PIPE to pipe the output back into variables for use here
‘’’
piped = {}
process = subprocess.Popen(’{0} {1}’.format(self.p4Command, args), stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.PIPE)
piped[‘stdout’], piped[‘stderr’] = process.communicate()
return piped
Yeah, we have a bit of this in house. It’s fine for simple commands. They’ve put quite a bit of effort into the the C++/Python support though. For instance, editing changelists and other “forms” through their API is done on a dictionary of fields returned by the libs. Editing forms from the command line is pretty awkward and it would take a fair bit of effort to come up to their level of completeness.
And the usual question:
“Moving to 2016?” Have P4API.pyd compiled for it yet?
on that note, i am developing a perforce wrapper in python that uses processes only, no compiled extension. I’m trying to make it as pythonic as possible. Is this something you guys would be interested in? I keep hitting the wall of “is this even worth it?”
I’d love to move to 2016, though. Building extensions shouldn’t be too difficult
Since the Perforce Python API is supported by Perforce themselves, I don’t see a ton of value in reimplementing it. There may be a few folks out there who need to run in a more vanilla environment, but it hasn’t been an issue for us to use the .pyd.
we have switched over to 2016. a few minor bugs encountered so far, but so far nothing that throws a wrench into our pipeline.
A good high-quality p4API replacement would be nice to have, I’ve done a few half assed ones over the years, but there is a lot of room for improvement to the public face of the API: p4Python is very close to the C API so everybody ends up writing their own wrapper on top of it… or writing hundreds of try-catch, if-then routines to handle the fact that it does stupid things like “Ask me a question about 1 file and get back three answers which don’t even have the same fields in them”. Plus, the annual song and dance about getting the binaries updated has gotten very old. I’ve never put it under a profiler but I have a hard time believing that Python is the slow part of a P4 transaction.
Open Source community project opportunity! You can put it up on the techartmafia github if you want to get people involved.
ok i’ll plug away a little more. I has most(all) of the functionality we would typically use, but not at the completeness of the p4api. I’ll push to my github tonight.
Nope? Nobody compiled for 2016?
So I compiled up the latest version of P4Python with OpenSSL-1.0.2c, this should work with both Maya2015 and Maya2016, I built a whl, egg, and zip file.
Located here.
Not sure how great OneDrive is for sharing this kind of thing, so if it breaks let me know and I’ll be less lazy and find a better place to stash these.
Dude, thank you, thank you. I’ll use these until I migrate over to TheMaxx’s python-perforce package.