Today I downloaded and installed Netbeans 6.7. My first impressions are very good. The performance seems better and I really like what was done for unit testing.
I have used it under Windows and Linux. Thanks Netbeans team!! Another great version delivered right on time.
Monday, June 29, 2009
Tuesday, June 23, 2009
HOWTO: Install Python Soap Libraries ZSI + SOAPpy + PyXML Under (of all things) Windows XP
Overview
I recently needed do some simple scripting using Python under Windows. The main goal was to test some web service calls (via SOAP). Python lets you put something like this together pretty quickly. Including WSDL processing, business logic, and unit testing.
Adding a SOAP library (ZSI+SOAPpy in this case) under linux (ubuntu or fedora) is also simple since you just install a package from a repo. However, I found that setting is up under Windows to be more of a pain.
Problem
Get ZSI, SOAPpy, fpconst, and PyXML setup for use in SOAP programming under Python 2.6.
The main issue is that one of the dependancies, PyXML, does not have a package for versions of Python > 2.4. This means that it will need to be manually built. The typical setup.py usually does the trick but for PyXML a C module was also included as part of the distro. Compiling modules under Windows requires an open source compiler or Visual Studio 2008. For me, neither are an option. Man I wish I could just use linux :-)
Lets Begin
After you fetch the packages through the Python Website...
Install fpconst
This, I think, is needed by SOAPpy. Fetch fpconst-0.7.2.tar.gz
Install PyXML
PyXML is required by SOAPpy and possibly ZSI. The problem you will run into installing it is that there are a few Python extensions that need compiled and unless you have Visual Studio 2008, it will not compile under Python 2.6.
Fortunatally, I discovered that SOAPpy (or ZSI) don't use these extensions so as long as you don't need it yourself you can install it as follows.
Installing SOAPpy
With PyXML installed, the hard part is over.
Install ZSI
Now the dependencies are install, ZSI can be installed. This is what you will use for all your SOAP calls. It is pretty well documented and fairly easy to use. The approach is similar to how it is handled in Java or .NET. Install is simple
Does it work?
To test, you will first need to process your web service WSDL file into something Python can work with. The approach is similar to what is done when you add a web service reference in .NET or JAVA. This this case, you use a simple command line utility called wsdl2py. On my windows computer, it is found in C:\Python26\Scripts\ You should find it in a similar place. Assuming that you do not have this script in the path and have not been clever enough to make a batch file, you can run it as follows. CD to the directory where you want your PY files created by the utility to go.
python C:\Python26\Scripts\wsdl2py -bu http://moneycow.sandwich.lan:8888/moneyfinder.asmx?WSDL
There are more parameters, but this command will get you what you need. You may see a few deprecation warnings but they don't hurt anything. In the end, you will get two files.
Unknowns
I have not figured out how to get SSL to work with ZSI. If any of you have figured this out, please post me a message. I would love to hear about it. It is not an issue for me now since none of the services I need to consume are Internet exposed. If I get stuck and need to access one, I will just use Java or .NET ;-)
Conclusion
If you have to use Windows and need to do Web Services with Python 2.6, the above steps should get you setup and ready to role. Once you are setup and get your first basic program working, you will find that Python does a good job and the performance is just fine.
I recently needed do some simple scripting using Python under Windows. The main goal was to test some web service calls (via SOAP). Python lets you put something like this together pretty quickly. Including WSDL processing, business logic, and unit testing.
Adding a SOAP library (ZSI+SOAPpy in this case) under linux (ubuntu or fedora) is also simple since you just install a package from a repo. However, I found that setting is up under Windows to be more of a pain.
Problem
Get ZSI, SOAPpy, fpconst, and PyXML setup for use in SOAP programming under Python 2.6.
The main issue is that one of the dependancies, PyXML, does not have a package for versions of Python > 2.4. This means that it will need to be manually built. The typical setup.py usually does the trick but for PyXML a C module was also included as part of the distro. Compiling modules under Windows requires an open source compiler or Visual Studio 2008. For me, neither are an option. Man I wish I could just use linux :-)
Lets Begin
After you fetch the packages through the Python Website...
Install fpconst
This, I think, is needed by SOAPpy. Fetch fpconst-0.7.2.tar.gz
- Under Windows I use WinRAR to extract the setup/temp folder
- run: python setup.py build
- run: python setup.py install
Install PyXML
PyXML is required by SOAPpy and possibly ZSI. The problem you will run into installing it is that there are a few Python extensions that need compiled and unless you have Visual Studio 2008, it will not compile under Python 2.6.
Fortunatally, I discovered that SOAPpy (or ZSI) don't use these extensions so as long as you don't need it yourself you can install it as follows.
- Under Windows I use WinRAR to extract the setup/temp folder
- run: python setup.py install --force -skip-build
Installing SOAPpy
With PyXML installed, the hard part is over.
- Unzip SOAPpy-0.12.0.zip to a setup/temp folder
- run: python setup.py build
- run: python setup.py install
Install ZSI
Now the dependencies are install, ZSI can be installed. This is what you will use for all your SOAP calls. It is pretty well documented and fairly easy to use. The approach is similar to how it is handled in Java or .NET. Install is simple
- WinRAR ZSI-2.0.tar.gz to a setup/temp folder
- run: python setup.py build
- run: python setup.py install
Does it work?
To test, you will first need to process your web service WSDL file into something Python can work with. The approach is similar to what is done when you add a web service reference in .NET or JAVA. This this case, you use a simple command line utility called wsdl2py. On my windows computer, it is found in C:\Python26\Scripts\ You should find it in a similar place. Assuming that you do not have this script in the path and have not been clever enough to make a batch file, you can run it as follows. CD to the directory where you want your PY files created by the utility to go.
python C:\Python26\Scripts\wsdl2py -bu http://moneycow.sandwich.lan:8888/moneyfinder.asmx?WSDL
There are more parameters, but this command will get you what you need. You may see a few deprecation warnings but they don't hurt anything. In the end, you will get two files.
- *_services.py
- *_services_types.py
Unknowns
I have not figured out how to get SSL to work with ZSI. If any of you have figured this out, please post me a message. I would love to hear about it. It is not an issue for me now since none of the services I need to consume are Internet exposed. If I get stuck and need to access one, I will just use Java or .NET ;-)
Conclusion
If you have to use Windows and need to do Web Services with Python 2.6, the above steps should get you setup and ready to role. Once you are setup and get your first basic program working, you will find that Python does a good job and the performance is just fine.
Sunday, May 31, 2009
Subversion - Checking out a Project
Overview
When it is time to get work done, code will need to be checked out. The main steps to checkout code that was imported as described in a previous post is as follows:
The following steps will checkout the sqlbuilder project that is part of the perl repo into my local filesystem's sqlbuilder folder.
Create new folder called sqlbuilder. My code is targeted to be on my local file system in a base directory of ~/work/perl/sqlbuilder
cd ~/work/perl/
mkdir sqlbuilder
cd sqlbuilder
svn checkout https://www.inhouse.stoken.net/repos/perl/sqlbuilder/trunk/ ./
Now your code is in a subversion managed folder.
Tagging Current Trunk
Tagging is a common practice in which you create a snapshot of your code as it stood in time or within a version. In this example, the sqlbuilder code needs to be tagged. The tagged version will be stored in the repo within a 20090528 folder.
svn -m 'tagging first release' copy https://www.inhouse.stoken.net/repos/perl/sqlbuilder/trunk/ https://www.inhouse.stoken.net/repos/perl/sqlbuilder/tags/20090528
Use a browser to view trunk and tag using the above URLs.
Final Thoughts
The process of checking out a tagged version is the same as for a trunk version, just ensure that the URL path is correct and it will work.
I personally tag frequently in Subversion since Subversion does it pretty efficiently. Your thoughts may vary on this.
This concludes the series on basic Subversion usage. When I have time, I will post something on Subversion + Netbeans. Netbeans handles Subversion very well but there are few small details that may help. I will post them soon.
When it is time to get work done, code will need to be checked out. The main steps to checkout code that was imported as described in a previous post is as follows:
- Create a workspace folder for your project
- Change directory into that folder
- Checkout code from the trunk (or tag or even branch) into the current directory.
The following steps will checkout the sqlbuilder project that is part of the perl repo into my local filesystem's sqlbuilder folder.
Create new folder called sqlbuilder. My code is targeted to be on my local file system in a base directory of ~/work/perl/sqlbuilder
cd ~/work/perl/
mkdir sqlbuilder
cd sqlbuilder
svn checkout https://www.inhouse.stoken.net/repos/perl/sqlbuilder/trunk/ ./
Now your code is in a subversion managed folder.
Tagging Current Trunk
Tagging is a common practice in which you create a snapshot of your code as it stood in time or within a version. In this example, the sqlbuilder code needs to be tagged. The tagged version will be stored in the repo within a 20090528 folder.
svn -m 'tagging first release' copy https://www.inhouse.stoken.net/repos/perl/sqlbuilder/trunk/ https://www.inhouse.stoken.net/repos/perl/sqlbuilder/tags/20090528
Use a browser to view trunk and tag using the above URLs.
Final Thoughts
The process of checking out a tagged version is the same as for a trunk version, just ensure that the URL path is correct and it will work.
I personally tag frequently in Subversion since Subversion does it pretty efficiently. Your thoughts may vary on this.
This concludes the series on basic Subversion usage. When I have time, I will post something on Subversion + Netbeans. Netbeans handles Subversion very well but there are few small details that may help. I will post them soon.
Subversion - Importing a new Project
Overview
Once a repo has been created, it is time to import your code. This has only a few main steps.
In this example, I have created a simple helper project called sqlbuider.
As described above, the first step is to create the base directory within the repo.
svn mkdir -m 'adding new project area' https://www.inhouse.stoken.net/repos/perl/sqlbuilder
Next, the standard subversion directory tree needs to be created.
svn mkdir -m 'adding new project area' https://www.inhouse.stoken.net/repos/perl/sqlbuilder/branches
svn mkdir -m 'adding new project area' https://www.inhouse.stoken.net/repos/perl/sqlbuilder/tags
svn mkdir -m 'adding new project area' https://www.inhouse.stoken.net/repos/perl/sqlbuilder/trunk
If you are building your repo as you are reading along, you should be able to point your browser to it and see an empty folder for .../tags .../trunk .../branches
We are ready for the next step, Import the project. On the local system, change directory to local project folder (sqlbuilder in my case) and import. My local source happens to be in ~/work/perl/sqlbuilder. Subversion doesn't care about the location. Just that you are sitting in the project folder. The following will import the project
cd ~/work/perl/sqlbuilder
svn -m 'inital import' import ./ https://www.inhouse.stoken.net/repos/perl/sqlbuilder/trunk/
The command says, "using the message of 'initial import', import everything in ./ to https://..../trunk/
If you refresh your broswer in the trunk folder, you will see code.
Normally, I will take my local directory (sqlbuilder in my case) and rename it to something like sqlbuilder_pre_svn or sqlbuilder_old.
This process can be followed for multiple projects within the same repo. Just create the directory structure and then import your code into it.
When you are ready to work on the project, you will want to create a new sqlbuilder folder and checkout the https://..../trunk/ code into it. That will be described in my next post.
Final Thoughts
Why not import the folder sqlbuilder? Why import just the contents of the folder into trunk? The main reason is that it simplifies situations where you may have one or many versions of the same project checked out. Now you can checkout a trunk or tag version into whatever directory you want. It makes things easier to deal with. The only thing to remember is to check out after you create a local workspace folder before checking out into it.
The next post will describe howto check out and tag code.
Once a repo has been created, it is time to import your code. This has only a few main steps.
- Create a base directory within the repo with the project name
- Build the standard subversion project tree (tags, branches, trunk)
- Import code into trunk
In this example, I have created a simple helper project called sqlbuider.
As described above, the first step is to create the base directory within the repo.
svn mkdir -m 'adding new project area' https://www.inhouse.stoken.net/repos/perl/sqlbuilder
Next, the standard subversion directory tree needs to be created.
svn mkdir -m 'adding new project area' https://www.inhouse.stoken.net/repos/perl/sqlbuilder/branches
svn mkdir -m 'adding new project area' https://www.inhouse.stoken.net/repos/perl/sqlbuilder/tags
svn mkdir -m 'adding new project area' https://www.inhouse.stoken.net/repos/perl/sqlbuilder/trunk
If you are building your repo as you are reading along, you should be able to point your browser to it and see an empty folder for .../tags .../trunk .../branches
We are ready for the next step, Import the project. On the local system, change directory to local project folder (sqlbuilder in my case) and import. My local source happens to be in ~/work/perl/sqlbuilder. Subversion doesn't care about the location. Just that you are sitting in the project folder. The following will import the project
cd ~/work/perl/sqlbuilder
svn -m 'inital import' import ./ https://www.inhouse.stoken.net/repos/perl/sqlbuilder/trunk/
The command says, "using the message of 'initial import', import everything in ./ to https://..../trunk/
If you refresh your broswer in the trunk folder, you will see code.
Normally, I will take my local directory (sqlbuilder in my case) and rename it to something like sqlbuilder_pre_svn or sqlbuilder_old.
This process can be followed for multiple projects within the same repo. Just create the directory structure and then import your code into it.
When you are ready to work on the project, you will want to create a new sqlbuilder folder and checkout the https://..../trunk/ code into it. That will be described in my next post.
Final Thoughts
Why not import the folder sqlbuilder? Why import just the contents of the folder into trunk? The main reason is that it simplifies situations where you may have one or many versions of the same project checked out. Now you can checkout a trunk or tag version into whatever directory you want. It makes things easier to deal with. The only thing to remember is to check out after you create a local workspace folder before checking out into it.
The next post will describe howto check out and tag code.
Subversion - Adding a new Repo
Overview
Based on my previous post, you should now have a working and configured Subversion environment. Most of the work was done in Apache.
Now a repo is needed to store all related projects. Subversion is pretty flexible here. You can create a repo per project, on single repo for everything, or do what I do. Create a repo per language you work in. For example:
Procedure
For this example, I am adding a new repo for my perl code projects. All my repos are stored in /opt/intranet/svn/
to create a new repo:
• cd /opt/intranet/svn
• svnadmin create perl
• chown -R apache:apache perl/
Within each repo, one or many projects. The following shows how to prepare and import files into a new project.
Final Thoughts
With this repo created, new projects can be added.
Based on my previous post, you should now have a working and configured Subversion environment. Most of the work was done in Apache.
Now a repo is needed to store all related projects. Subversion is pretty flexible here. You can create a repo per project, on single repo for everything, or do what I do. Create a repo per language you work in. For example:
- /opt/intranet/svn/python/
- /opt/intranet/svn/ruby/
- /opt/intranet/svn/java/
- /opt/intranet/svn/php/
Procedure
For this example, I am adding a new repo for my perl code projects. All my repos are stored in /opt/intranet/svn/
to create a new repo:
• cd /opt/intranet/svn
• svnadmin create perl
• chown -R apache:apache perl/
Within each repo, one or many projects. The following shows how to prepare and import files into a new project.
Final Thoughts
With this repo created, new projects can be added.
Subscribe to:
Posts (Atom)