Me neither at this rate but will try! - have a good break,

Dom.

On 19/07/10 14:46, Kralidis,Tom [Ontario] wrote:

Dom: thanks for the info.  Alas, I won't be able to get to this until
September.  Let me know how things go, and / or I will test when I get
back from holidays.

..Tom


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Dominic Lowe
Sent: Tuesday, 13 July 2010 04:49
To: [email protected]
Subject: Re: [Community] About time for a new release of OWSlib?

Hi Tom,

Yes, I should have explained this.

Installing the final release from PyPi will be
straightforward, but the development install is now a bit
more complicated.

To deal with the final release first -  users can just
easy_install OWSLib as normal. The setup config for OWSLib
then tells easy install to also install owslib.csw,
owslib.wms etc (or whichever packages we decide to put in the
final release). So users won't notice any changes - the api
is the same and the install process is the same.

For development purposes the easiest way is to install the
components you need to work with as 'develop' eggs.

So check out everything then go into your owslib.common code and do:
python setup.py develop

Then go into the owslib.csw package and do python setup.py develop

You have to do it in this order as owslib.csw depends on
owslib.common as you point out.

Your python 'site-packages' eggs for csw and common will then
link back to the code in your development checkout. Any
changes to the code will be reflected in your python
site-packages (it's just a link).

That's it. At the moment the tests are all together so you
will have to install the other services if you want to run
all the tests - this is something we should probably look at.

It would also be good to write a dev install script but I
haven't done this either.

Hope that helps,  let me know how you get on.

Cheers,
Dom




On 12/07/10 16:54, Kralidis,Tom [Ontario] wrote:

Dom: thanks for this.  How are the dependencies handled?  i.e.
owslib.csw needs util.py (which is now in owslib.common.

..Tom


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf
Of Dominic
Lowe
Sent: Friday, 09 July 2010 04:39
To: [email protected]
Subject: Re: [Community] About time for a new release of OWSlib?

Tom, Sean and all,

Sorry I forgot to email about this -

I made a new namespaced branch about a week ago with a
view to moving
it towards the trunk - but how do you want to play this? We could
test and fix in the branch or switch the branch to the
trunk now and
then begin testing it.

New branch can be seen here:

http://trac.gispython.org/lab/browser/OWSLib/branches/ns_refactor


Cheers,

Dom

On 21/06/10 14:25, Kralidis,Tom [Ontario] wrote:



-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf
Of Dominic
Lowe
Sent: Friday, 18 June 2010 06:17
To: [email protected]
Subject: [Community] About time for a new release of OWSlib?


It's been over a year since the last release of OWSLib
and in that
time there have been a lot of changes including:

    >    >    * CSW support
    >    >    * ISO 19115 metadata parsing (needed for CSW support I
assume)>    >    * Several improvements to WCS support
(caching, url
checking)>    >    * OWSCommon classes to share between
services>    >    * A general Utils module for common functions

Last time we discussed this I had a look at breaking up the
individual services into separate eggs under an owslib namespace.
This would enable us to release eggs for different services
individually and on a quicker timescale. I think this will be of
benefit in the long run - even to Tom who was against
the idea ;-)

I still think this is a good plan for long term
sustainability but
the thing that stalled the last release (on my part!) was
the effort
needed to make the switch and reorganise the codebase.

I did get as far as trying it out though and it worked:
http://trac.gispython.org/lab/browser/OWSLib/branches/namespac
ePkgsTest

So I'm prepared to put in the effort to make the complete
switch this
time but to do so I think we will effectively need to freeze the
current trunk and tests for a while so the code can be
refactored. (I
will do the refactoring in a branch, but I don't want to have a
subsequent merge nightmare!).

If I get it to this stage where it is structurally
ready, then it
would be good if other OWSlib developers could support this by
helping out with testing in particular.

I think once we get over this hurdle future (service
specific..) releases will be much easier.

Tom, you are most actively working on the trunk. Are you
happy to see
it effectively frozen now?


Yes (as of r1662), let us know when we can commit again.

Cheers,
Dom







_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community

_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community

_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community

_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community

_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community

_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community

_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community

Reply via email to