[p4] PYPERFORCE

[Weintraub, David]

I am not a Python programmer, and I don't know too much about
PyPerforce, but I do use similar APIs for Perl and Ruby.

You don't need an API like PyPerforce to use a scripting language like
Python together with Perforce. For example, both Perl and Ruby give me
ways of interacting with external commands, and I assume Python has the
same types of mechanisms. That means, I can use the built in mechanisms
in my scripting language to run the Perforce commands I need, and to
manipulate their input and output. In Perl, this is done via the qx()
command (which executes a command, and sends its output to a Perl
variable) and the open statement (which treats the input and output of
Perforce commands as text files).  In Ruby, it is the IO::popen
statement (which treats the input and output of the Perforce commands as
text files and is probably closer to the way Python would do it).

So if you don't need an API like PyPerforce, why use it? After all, you
now have to learn this module's interface, and you have to download and
install this API module for each machine where you want to execute your
Python script. Maintainability is harder because anyone who is
maintaining your scripts now has to realize that you are using this
module. If you move servers, it's another thing that must be installed.
It certainly seems like a lot of work for something with such a limited
scope.

So why go through that bother? For one, these modules give you a
standard and easy way to manipulate Perforce forms. In Perl, form fields
are read into a hashtable array which makes it much easier to manipulate
the different fields of the form than executing a Perforce command,
sending its output to a temporary file, parsing that file, writing
another temporary file with the changes, then reading that new temporary
file into a new Perforce command. (Whoops, did you remember to delete
the temporary files?)

In fact, if you work with Perforce enough, you'll end up writing your
own Perforce API just to more easily manipulate these forms and handle
various tasks. Of course, you'll have to debug your new modules, then
let everyone know that you have these special modules that must be
downloaded, maintained, and installed, and... Well, you pretty much end
up doing what you did before with the standard modules. Except of
course, a new Perforce person probably knows the standard module like
PyPerforce, and doesn't know too much about your module. You end up with
the same problems, more bugs, and more confusion.

Another reason is the way Perforce handles errors. In standard Unix,
commands return a exit code of zero when they work, and a non-zero when
they don't. Perforce claims that the "p4" command does the same thing.
However, for standard Unix commands, the word "error" has a much
different meaning than the way Perforce uses it. For example, the Unix
command "ls" lists the files in my directory. If I say "ls foo", and the
file "foo" doesn't exist, the "ls" command returns a non-zero error
code. It's not that the "ls" command failed. It did what it was suppose
to do (it tells me "file 'foo' doesn't exist). However, it decides to
alert me to the possibility that I expected "foo", and didn't find it.

Perforce takes the tack that unless a terrible error happens, the "p4"
command doesn't fail. For example, if I do "p4 sync", and I am not
logged into Perforce, the "p4" command doesn't sync my directory, but it
doesn't return a non-zero error code. According to Perforce, the "p4
sync" didn't fail. It might not have done what I thought it wasn't going
to do, but that's not the "p4 sync" command's fault. Imagine writing a
script that uses the "p4 sync" command and needing to determine if the
sync succeeded. Simply checking the return exit code of "p4 sync" won't
work.

The various APIs give you a way of checking the results of the Perforce
command and seeing if the command really did work. In Perl and Ruby, I
can check an array of error messages, and see if it is empty. If it is,
I can safely assume my Perforce command really did work.

The final reason to use the API is that the API doesn't run the Perforce
commands from the command line, but instead directly accesses the
Perforce API's library. If I don't use the API, I am first executing a
command "shell", loading the shell's environment, executing the "p4"
command, and finally having that "p4" command access the Perforce API's
library. By using the API, I eliminate that overhead speed up my
execution, and put less load on the server.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of harish A.S.
Sent: Tuesday, September 05, 2006 7:25 AM
To: perforce-user at perforce.com
Subject: [p4] PYPERFORCE

HY
thank you for the response...I am getting a better grip in understanding
pyperforce...
Since you ppl are using this interface(PYPERFORCE)....how many of you
recommend me to use this...
Ive aldready decided to use PERFORCE as my SCM..But i still have my
doubts on PYPERFORCE!
Are there any performance based problems(isues) with PYPERFORCE?
If so how intense are they?
AND seriously speaking     How many of you recommend me to use
PYPERFORCE?with reasons pls....if possible can you ppl give me better
alternatives to PYPERFORCE-If and only the substitute is good enough 
thanks a lot
regards
harryy
 		
---------------------------------
 All-new Yahoo! Mail - Fire up a more powerful email and get things done
faster.
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user