Namespace packages sanity check -OWSLib

[Dominic Lowe-2]

All (especially Sean & Tom),

As discussed I've just rejigged all the OWSLib code into separate eggs under a
single namespace package  as you can see here:

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

And checkout from here:
svn co http://svn.gispython.org/svn/gispy/OWSLib/branches/namespacePkgsTest/ 
mytestdir

When you have a moment could you please take a look at all this and see if it
makes sense and works for you? There are eggs for each service, which will
need building separately as far as I can tell - unless anyone has a better
way.

The OWSLib egg itself, depends on all the other services except owslib.sos,
which Tom says isn't mature enough to go into the final distribution - so
(when released) "easy install OWSLib" should get you all the service eggs
except SOS. Alternatively you will be able to do "easy install OWSLib.wfs"
for example.

I've also added an owslib.common package, which contains OGC OWSCommon
modules, and other 'common' modules such as etree. Each service egg depends
on owslib.common.

Anyway - I'd really like someone else to take a look at this and check I
haven't scrambled/fried/overcooked the eggs.  

Some questions:
1) What's the best way to install all these eggs for development? I ended up
doing "python setup.py develop" on each egg individually. Maybe that's okay
though as you won't normally be working on all the eggs at once.

2) What about tests - currently they are in the main owslib package but it
would be nice to distribute them. But then we'd have to strap them back
together again to run them as a batch. Any ideas?

3) Multiple service versions.. eg the WCS egg contains clients for wcs 1.0 and
1.1 - ideally these should be distributed separately... I don't think it's a
showstopper though at the moment.

Cheers,

Dom

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Sean Gillies-2]

Hi Dom,

I'm sorry I haven't had time to look at this yet. Some comments ...

On Oct 28, 2009, at 4:35 PM, Dominic Lowe wrote:

> All (especially Sean & Tom),
>
> As discussed I've just rejigged all the OWSLib code into separate  
> eggs under a
> single namespace package  as you can see here:
>
> http://trac.gispython.org/lab/browser/OWSLib/branches/ 
> namespacePkgsTest
>
> And checkout from here:
> svn co http://svn.gispython.org/svn/gispy/OWSLib/branches/namespacePkgsTest/
> mytestdir
>
> When you have a moment could you please take a look at all this and  
> see if it
> makes sense and works for you? There are eggs for each service,  
> which will
> need building separately as far as I can tell - unless anyone has a  
> better
> way.
>
> The OWSLib egg itself, depends on all the other services except  
> owslib.sos,
> which Tom says isn't mature enough to go into the final distribution  
> - so
> (when released) "easy install OWSLib" should get you all the service  
> eggs
> except SOS. Alternatively you will be able to do "easy install  
> OWSLib.wfs"
> for example.
>
> I've also added an owslib.common package, which contains OGC OWSCommon
> modules, and other 'common' modules such as etree. Each service egg  
> depends
> on owslib.common.
>
> Anyway - I'd really like someone else to take a look at this and  
> check I
> haven't scrambled/fried/overcooked the eggs.
>
> Some questions:
> 1) What's the best way to install all these eggs for development? I  
> ended up
> doing "python setup.py develop" on each egg individually. Maybe  
> that's okay
> though as you won't normally be working on all the eggs at once.
>

Yes, develop for each. A build framework can make this easier. I use  
zc.buildout for some things, but I'd bet you could do it with Paver.  
Or a bash script?

> 2) What about tests - currently they are in the main owslib package  
> but it
> would be nice to distribute them. But then we'd have to strap them  
> back
> together again to run them as a batch. Any ideas?
>

How about the nose test runner? From the directory containing all the  
checkouts, you could do something like (which I haven't actually tried)

   $ PYTHONPATH=LIST_OF_DEVELOP_EGGS nose owslib/tests owslib.common/
tests ...

Zope's test runner can test multiple packages too.

> 3) Multiple service versions.. eg the WCS egg contains clients for  
> wcs 1.0 and
> 1.1 - ideally these should be distributed separately... I don't  
> think it's a
> showstopper though at the moment.

Agreed. I wish I had more time to try out these suggestions, but I'm a  
bit submerged in a different project.

>
> Cheers,
>
> Dom
>
> _______________________________________________
> Community mailing list
> Community@...
> http://lists.gispython.org/mailman/listinfo/community

--
Sean

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Kralidis,Tom [Ontario]]

Hi Dom: why would we need to break these out per standard, even per version?  Call me simplistic, but installing the whole lib would give the user access to each standard and version as they wish.  I don't think we are at a point where the codebase is too big to deploy in full.

Cheers

..Tom


-----Original Message-----
From: community-bounces@... on behalf of Dominic Lowe
Sent: Wed 28-Oct-09 11:35
To: gispython.org community projects
Subject: [Community] Namespace packages sanity check -OWSLib
 
All (especially Sean & Tom),

As discussed I've just rejigged all the OWSLib code into separate eggs under a
single namespace package  as you can see here:

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

And checkout from here:
svn co http://svn.gispython.org/svn/gispy/OWSLib/branches/namespacePkgsTest/ 
mytestdir

When you have a moment could you please take a look at all this and see if it
makes sense and works for you? There are eggs for each service, which will
need building separately as far as I can tell - unless anyone has a better
way.

The OWSLib egg itself, depends on all the other services except owslib.sos,
which Tom says isn't mature enough to go into the final distribution - so
(when released) "easy install OWSLib" should get you all the service eggs
except SOS. Alternatively you will be able to do "easy install OWSLib.wfs"
for example.

I've also added an owslib.common package, which contains OGC OWSCommon
modules, and other 'common' modules such as etree. Each service egg depends
on owslib.common.

Anyway - I'd really like someone else to take a look at this and check I
haven't scrambled/fried/overcooked the eggs.  

Some questions:
1) What's the best way to install all these eggs for development? I ended up
doing "python setup.py develop" on each egg individually. Maybe that's okay
though as you won't normally be working on all the eggs at once.

2) What about tests - currently they are in the main owslib package but it
would be nice to distribute them. But then we'd have to strap them back
together again to run them as a batch. Any ideas?

3) Multiple service versions.. eg the WCS egg contains clients for wcs 1.0 and
1.1 - ideally these should be distributed separately... I don't think it's a
showstopper though at the moment.

Cheers,

Dom

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Sean Gillies-2]

Tom,

To me, it's not about the size, it's about not shipping half-baked  
stuff. Different parts (for different standards) are developing at  
separate paces. Separating them lets each be released at their own  
rate without holding up the others. A WYS that has just begun and  
doesn't work wouldn't hold up a WZS that was fully ready.

On Nov 10, 2009, at 6:43 PM, Kralidis,Tom [Ontario] wrote:

>
> Hi Dom: why would we need to break these out per standard, even per  
> version?  Call me simplistic, but installing the whole lib would  
> give the user access to each standard and version as they wish.  I  
> don't think we are at a point where the codebase is too big to  
> deploy in full.
>
> Cheers
>
> ..Tom
>
>
> -----Original Message-----
> From: community-bounces@... on behalf of Dominic Lowe
> Sent: Wed 28-Oct-09 11:35
> To: gispython.org community projects
> Subject: [Community] Namespace packages sanity check -OWSLib
>
> All (especially Sean & Tom),
>
> As discussed I've just rejigged all the OWSLib code into separate  
> eggs under a
> single namespace package  as you can see here:
>
> http://trac.gispython.org/lab/browser/OWSLib/branches/ 
> namespacePkgsTest
>
> And checkout from here:
> svn co http://svn.gispython.org/svn/gispy/OWSLib/branches/namespacePkgsTest/
> mytestdir
>
> When you have a moment could you please take a look at all this and  
> see if it
> makes sense and works for you? There are eggs for each service,  
> which will
> need building separately as far as I can tell - unless anyone has a  
> better
> way.
>
> The OWSLib egg itself, depends on all the other services except  
> owslib.sos,
> which Tom says isn't mature enough to go into the final distribution  
> - so
> (when released) "easy install OWSLib" should get you all the service  
> eggs
> except SOS. Alternatively you will be able to do "easy install  
> OWSLib.wfs"
> for example.
>
> I've also added an owslib.common package, which contains OGC OWSCommon
> modules, and other 'common' modules such as etree. Each service egg  
> depends
> on owslib.common.
>
> Anyway - I'd really like someone else to take a look at this and  
> check I
> haven't scrambled/fried/overcooked the eggs.
>
> Some questions:
> 1) What's the best way to install all these eggs for development? I  
> ended up
> doing "python setup.py develop" on each egg individually. Maybe  
> that's okay
> though as you won't normally be working on all the eggs at once.
>
> 2) What about tests - currently they are in the main owslib package  
> but it
> would be nice to distribute them. But then we'd have to strap them  
> back
> together again to run them as a batch. Any ideas?
>
> 3) Multiple service versions.. eg the WCS egg contains clients for  
> wcs 1.0 and
> 1.1 - ideally these should be distributed separately... I don't  
> think it's a
> showstopper though at the moment.
>
> Cheers,
>
> Dom
>
> _______________________________________________
> Community mailing list
> Community@...
> http://lists.gispython.org/mailman/listinfo/community
>
> _______________________________________________
> Community mailing list
> Community@...
> http://lists.gispython.org/mailman/listinfo/community

--
Sean

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Kralidis,Tom [Ontario]]

Fair enough.  I guess I'm knee deep in MapServer release style, where we
release even with partial support.

..Tom
 

> -----Original Message-----
> From: community-bounces@...
> [mailto:community-bounces@...] On Behalf Of
> Sean Gillies
> Sent: Tuesday, 10 November 2009 16:11
> To: gispython.org community projects
> Subject: Re: [Community] Namespace packages sanity check -OWSLib
>
> Tom,
>
> To me, it's not about the size, it's about not shipping
> half-baked stuff. Different parts (for different standards)
> are developing at separate paces. Separating them lets each
> be released at their own rate without holding up the others.
> A WYS that has just begun and doesn't work wouldn't hold up a
> WZS that was fully ready.
>
> On Nov 10, 2009, at 6:43 PM, Kralidis,Tom [Ontario] wrote:
>
> >
> > Hi Dom: why would we need to break these out per standard, even per
> > version?  Call me simplistic, but installing the whole lib
> would give
> > the user access to each standard and version as they wish.  I don't
> > think we are at a point where the codebase is too big to deploy in
> > full.
> >
> > Cheers
> >
> > ..Tom
> >
> >
> > -----Original Message-----
> > From: community-bounces@... on behalf of
> Dominic Lowe
> > Sent: Wed 28-Oct-09 11:35
> > To: gispython.org community projects
> > Subject: [Community] Namespace packages sanity check -OWSLib
> >
> > All (especially Sean & Tom),
> >
> > As discussed I've just rejigged all the OWSLib code into
> separate eggs
> > under a single namespace package  as you can see here:
> >
> > http://trac.gispython.org/lab/browser/OWSLib/branches/
> > namespacePkgsTest
> >
> > And checkout from here:
> > svn co
> >
> http://svn.gispython.org/svn/gispy/OWSLib/branches/namespacePkgsTest/
> > mytestdir
> >
> > When you have a moment could you please take a look at all this and
> > see if it makes sense and works for you? There are eggs for each
> > service, which will need building separately as far as I can tell -
> > unless anyone has a better way.
> >
> > The OWSLib egg itself, depends on all the other services except
> > owslib.sos, which Tom says isn't mature enough to go into the final
> > distribution
> > - so
> > (when released) "easy install OWSLib" should get you all
> the service
> > eggs except SOS. Alternatively you will be able to do "easy install
> > OWSLib.wfs"
> > for example.
> >
> > I've also added an owslib.common package, which contains
> OGC OWSCommon
> > modules, and other 'common' modules such as etree. Each service egg
> > depends on owslib.common.
> >
> > Anyway - I'd really like someone else to take a look at
> this and check
> > I haven't scrambled/fried/overcooked the eggs.
> >
> > Some questions:
> > 1) What's the best way to install all these eggs for development? I
> > ended up doing "python setup.py develop" on each egg individually.
> > Maybe that's okay though as you won't normally be working
> on all the
> > eggs at once.
> >
> > 2) What about tests - currently they are in the main owslib package
> > but it would be nice to distribute them. But then we'd have
> to strap
> > them back together again to run them as a batch. Any ideas?
> >
> > 3) Multiple service versions.. eg the WCS egg contains
> clients for wcs
> > 1.0 and
> > 1.1 - ideally these should be distributed separately... I
> don't think
> > it's a showstopper though at the moment.
> >
> > Cheers,
> >
> > Dom
> >
> > _______________________________________________
> > Community mailing list
> > Community@...
> > http://lists.gispython.org/mailman/listinfo/community
> >
> > _______________________________________________
> > Community mailing list
> > Community@...
> > http://lists.gispython.org/mailman/listinfo/community
>
> --
> Sean
>
> _______________________________________________
> Community mailing list
> Community@...
> http://lists.gispython.org/mailman/listinfo/community
>

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Dominic Lowe-2]

I agree with this, and that was the motivation. At the moment there's a mix of very mature code and very new code - it's not clear to users what to expect. However just to clarify you will still be able to easy install OWSLib and get all the fully released components together - and we can define what versions of the other eggs are deployed by this package. But anything that is still clearly beta code would need installing separately.

Cheers,
Dom

-----Original Message-----
From: community-bounces@... on behalf of Sean Gillies
Sent: Tue 10/11/2009 21:11
To: gispython.org community projects
Subject: Re: [Community] Namespace packages sanity check -OWSLib
 
Tom,

To me, it's not about the size, it's about not shipping half-baked  
stuff. Different parts (for different standards) are developing at  
separate paces. Separating them lets each be released at their own  
rate without holding up the others. A WYS that has just begun and  
doesn't work wouldn't hold up a WZS that was fully ready.

On Nov 10, 2009, at 6:43 PM, Kralidis,Tom [Ontario] wrote:

>
> Hi Dom: why would we need to break these out per standard, even per  
> version?  Call me simplistic, but installing the whole lib would  
> give the user access to each standard and version as they wish.  I  
> don't think we are at a point where the codebase is too big to  
> deploy in full.
>
> Cheers
>
> ..Tom
>
>
> -----Original Message-----
> From: community-bounces@... on behalf of Dominic Lowe
> Sent: Wed 28-Oct-09 11:35
> To: gispython.org community projects
> Subject: [Community] Namespace packages sanity check -OWSLib
>
> All (especially Sean & Tom),
>
> As discussed I've just rejigged all the OWSLib code into separate  
> eggs under a
> single namespace package  as you can see here:
>
> http://trac.gispython.org/lab/browser/OWSLib/branches/ 
> namespacePkgsTest
>
> And checkout from here:
> svn co http://svn.gispython.org/svn/gispy/OWSLib/branches/namespacePkgsTest/
> mytestdir
>
> When you have a moment could you please take a look at all this and  
> see if it
> makes sense and works for you? There are eggs for each service,  
> which will
> need building separately as far as I can tell - unless anyone has a  
> better
> way.
>
> The OWSLib egg itself, depends on all the other services except  
> owslib.sos,
> which Tom says isn't mature enough to go into the final distribution  
> - so
> (when released) "easy install OWSLib" should get you all the service  
> eggs
> except SOS. Alternatively you will be able to do "easy install  
> OWSLib.wfs"
> for example.
>
> I've also added an owslib.common package, which contains OGC OWSCommon
> modules, and other 'common' modules such as etree. Each service egg  
> depends
> on owslib.common.
>
> Anyway - I'd really like someone else to take a look at this and  
> check I
> haven't scrambled/fried/overcooked the eggs.
>
> Some questions:
> 1) What's the best way to install all these eggs for development? I  
> ended up
> doing "python setup.py develop" on each egg individually. Maybe  
> that's okay
> though as you won't normally be working on all the eggs at once.
>
> 2) What about tests - currently they are in the main owslib package  
> but it
> would be nice to distribute them. But then we'd have to strap them  
> back
> together again to run them as a batch. Any ideas?
>
> 3) Multiple service versions.. eg the WCS egg contains clients for  
> wcs 1.0 and
> 1.1 - ideally these should be distributed separately... I don't  
> think it's a
> showstopper though at the moment.
>
> Cheers,
>
> Dom
>
> _______________________________________________
> Community mailing list
> Community@...
> http://lists.gispython.org/mailman/listinfo/community
>
> _______________________________________________
> Community mailing list
> Community@...
> http://lists.gispython.org/mailman/listinfo/community

--
Sean

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

--
Scanned by iCritical.
_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community