[Geoserver-devel] fixing the python community module

GeoServer GeoServer Developer
1

Hi all,

Currently the python community module is disabled. The reason being that it requires some sources from the geoscript-py git repository. Originally I simply added this as as svn external but unfortunately github svn support is shoty at best, and fails often. My next shot at a solution would be to simply use git directly to check out the sources, executed via an ant script. I have used approach on other projects and it works well.

The downside then becomes that git would be required on the path to build the module… which probably is not a problem for most developers who are now using git and probably not a problem since most developers don’t build that community module. But I was wanted to check with folks regardless. If people think it will be too much headache I can try for another solution.

Thanks!

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

2

On Thu, Mar 31, 2011 at 4:41 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
Currently the python community module is disabled. The reason being that it
requires some sources from the geoscript-py git repository. Originally I
simply added this as as svn external but unfortunately github svn support is
shoty at best, and fails often. My next shot at a solution would be to
simply use git directly to check out the sources, executed via an ant
script. I have used approach on other projects and it works well.
The downside then becomes that git would be required on the path to build
the module... which probably is not a problem for most developers who are
now using git and probably not a problem since most developers don't build
that community module. But I was wanted to check with folks regardless. If
people think it will be too much headache I can try for another solution.

I don't see this as a problem as long as the module is a community one,
it also seems that you're basically the only one working on it at the moment
so no reason to make your life harder.

If/when the module becomes extension or core yeah, in that case we are
probably going to need some thinking on how to handle the issue for a larger
number of people.

My 2 cents :slight_smile:

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

3

On Thu, Mar 31, 2011 at 9:47 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Mar 31, 2011 at 4:41 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
Currently the python community module is disabled. The reason being that it
requires some sources from the geoscript-py git repository. Originally I
simply added this as as svn external but unfortunately github svn support is
shoty at best, and fails often. My next shot at a solution would be to
simply use git directly to check out the sources, executed via an ant
script. I have used approach on other projects and it works well.
The downside then becomes that git would be required on the path to build
the module… which probably is not a problem for most developers who are
now using git and probably not a problem since most developers don’t build
that community module. But I was wanted to check with folks regardless. If
people think it will be too much headache I can try for another solution.

I don’t see this as a problem as long as the module is a community one,
it also seems that you’re basically the only one working on it at the moment
so no reason to make your life harder.

If/when the module becomes extension or core yeah, in that case we are
probably going to need some thinking on how to handle the issue for a larger
number of people.

My 2 cents :slight_smile:

Cool, thanks Andrea. And I agree. I think once/if it moves to extension I will just grab a copy of the geoscript sources and include it in the module. However now since the geoscript sources change pretty rapidly it is nice to keep them as an external.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

4

I am concerned that this would break any svn-only build environment that uses -PallExtensions (if python was added back into this profile). All our developers (and our buildbot) build with -PallExtensions, and I am the only git user.

A compromise would be if your ant script failed gracefully if git was not present. Perhaps an empty or minimal src tree if git is not present? (What ever is necessary to appease maven and maven-surefire-plugin.)

We are currently an svn project, and changing to require git to build -PallExtensions is, in my view, a substantial step.

Kind regards,
Ben.

On 31/03/11 22:41, Justin Deoliveira wrote:

Hi all,

Currently the python community module is disabled. The reason being that it requires some sources from the geoscript-py git repository. Originally I simply added this as as svn external but unfortunately github svn support is shoty at best, and fails often. My next shot at a solution would be to simply use git directly to check out the sources, executed via an ant script. I have used approach on other projects and it works well.

The downside then becomes that git would be required on the path to build the module... which probably is not a problem for most developers who are now using git and probably not a problem since most developers don't build that community module. But I was wanted to check with folks regardless. If people think it will be too much headache I can try for another solution.

Thanks!

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

5

On Fri, Apr 1, 2011 at 8:40 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

I am concerned that this would break any svn-only build environment that
uses -PallExtensions (if python was added back into this profile). All
our developers (and our buildbot) build with -PallExtensions, and I am
the only git user.

A compromise would be if your ant script failed gracefully if git was
not present. Perhaps an empty or minimal src tree if git is not present?
(What ever is necessary to appease maven and maven-surefire-plugin.)

We are currently an svn project, and changing to require git to build
-PallExtensions is, in my view, a substantial step.

python is a community module, -PallExtensions does not build
anything in community as far as I know.
The close equivalent in community land is the -PcommunityRelease
profile, which is not normally used.

However you have a point, if anyone comes and wants to try out
the communityRelease profile, probably in order to add a new
module to the nightly community build, he/she will need git
around. This could indeed be annoying, though it seems that
lately only core developers are adding community modules (funny uh?)

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

6

Andrea, you are right. And it was not the build but the checkout that was causing python to break the build (I should know: I kicked it out of the build). I rescind my earlier objection!

Justin, I think restoring python is OK. I would still recommend failing gracefully in the absence of git.

On 01/04/11 14:56, Andrea Aime wrote:

python is a community module, -PallExtensions does not build
anything in community as far as I know.
The close equivalent in community land is the -PcommunityRelease
profile, which is not normally used.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

7

Yeah, I had the same thought just not sure about the best way to do it… Ideally we could add a profile that includes the module only when git is around… but I don’t know if that is possible in a profile activation. I may just take it out of the community profile proper and add a special profile for it. But for now hopefully just sitting in community it does not become too disruptive.

On Fri, Apr 1, 2011 at 1:50 AM, Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com wrote:

Andrea, you are right. And it was not the build but the checkout that was causing python to break the build (I should know: I kicked it out of the build). I rescind my earlier objection!

Justin, I think restoring python is OK. I would still recommend failing gracefully in the absence of git.

On 01/04/11 14:56, Andrea Aime wrote:

python is a community module, -PallExtensions does not build
anything in community as far as I know.
The close equivalent in community land is the -PcommunityRelease
profile, which is not normally used.

–

Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com

Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.