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: [email protected] 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: [email protected] 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 > [email protected] > http://lists.gispython.org/mailman/listinfo/community > > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community -- Sean _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community -- Scanned by iCritical. _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
