GNIP 29 - Code Repository Reorganization

[sbenthall]

https://github.com/GeoNode/geonode/wiki/GNIP-29---Code-Repository-Reorganization

It is proposed to re-organize the GeoNode core repository to make it more similar to a standard django project layout and make it more friendly to template projects as introduced in Django 1.4

[dwins]

This GNIP appears to be proposing a lot more than just rearranging the files in the code repository. I see several modules in the Django project mentioned (data, people, search, security, projects) which do not exist in the current repository.

Also implied is support for Django's new template system, which I'm not really opposed to but should be discussed more explicitly in the proposal.

Also, why are geonode-rpm, geonode-deb, geonode-registry, geonode-cloud etc. listed in the geonode/src/ directory? Are you proposing we move these into the main repository? I don't understand what motivates this move, and there is not much discussion in the proposal.

[dwins]

Also, in response to this comment from the proposal:

|--------- geonode-geoserver-ext/ (may no longer be required once new security subsystem is implemented)

The new security system in GeoServer does not replace all of the functionality in geonode-server-ext, and our security scheme is far from standardized. I don't see the GeoNode GeoServer extensions going away any time soon.

[jj0hns0n]

On Mon, Jun 4, 2012 at 12:19 PM, David Winslow
[email protected]
wrote:

This GNIP appears to be proposing a lot more than just rearranging the files in the code repository.  I see several modules in the Django project mentioned (data, people, search, security, projects) which do not exist in the current repository.

Those are just examples to show how it would work. data would be the
name of the core module after the refactor in GNIP 30. The rest would
be introduced by other GNIPs. But for purposes of this GNIP, they are
just examples.

Also implied is support for Django's new template system, which I'm not really opposed to but should be discussed more explicitly in the proposal.

There is a separate GNIP (7) for this.

Also, why are geonode-rpm, geonode-deb, geonode-registry, geonode-cloud etc. listed in the geonode/src/ directory? Are you proposing we move these into the main repository? I don't understand what motivates this move, and there is not much discussion in the proposal.

They were proposed as submodules. Ariel was opposed to this kind of
thing, and Im more or less ok with just NOT having the src directory
at all and moving geoserver-geonode-dev and geonode-client as top
level modules next to geonode itself.

---

Reply to this email directly or view it on GitHub:
#260 (comment)

[jj0hns0n]

On Mon, Jun 4, 2012 at 12:21 PM, David Winslow
[email protected]
wrote:

Also, in response to this comment from the proposal:

|--------- geonode-geoserver-ext/ (may no longer be required once new security subsystem is implemented)

The new security system in GeoServer does not replace all of the functionality in geonode-server-ext, and our security scheme is far from standardized.  I don't see the GeoNode GeoServer extensions going away any time soon.

Think this should live at the top level. next to the other ones. I
will update it.

---

Reply to this email directly or view it on GitHub:
#260 (comment)

[jj0hns0n]

Updated. https://github.com/GeoNode/geonode/wiki/GNIP-29---Code-Repository-Reorganization

Just to be clear though. It's my long-term intention that both
geoserver-geonode-ext and geonode-client both go away completely and
that we just just plain vanilla geoserver with some light
configuration and the same for geoexplorer (lightly configured for use
inside geonode). I see no (long term) reason to have these be separate
projects outside of the normal projects.

On Mon, Jun 4, 2012 at 12:25 PM, Jeffrey Johnson [email protected] wrote:

On Mon, Jun 4, 2012 at 12:21 PM, David Winslow
[email protected]
wrote:

Also, in response to this comment from the proposal:

|--------- geonode-geoserver-ext/ (may no longer be required once new security subsystem is implemented)

The new security system in GeoServer does not replace all of the functionality in geonode-server-ext, and our security scheme is far from standardized.  I don't see the GeoNode GeoServer extensions going away any time soon.

Think this should live at the top level. next to the other ones. I
will update it.

---

Reply to this email directly or view it on GitHub:
#260 (comment)

[sbenthall]

Ariel has mentioned that it would be great if we could get more committers to weigh in on GNIPs. We should probably soon make that a matter of explicit project policy. But I feel like for changes that will affect all developers like this GNIP, it is especially important.

[rmarianski]

Generally speaking, I'd prefer not to use submodules to include other repos, and instead rely on something like build automation to setup development environments.

In terms of scope, if it's just a matter of moving things around I'm +1 for reorganizations that make sense. But just to make sure I understand things correctly, does this gnip also include creating a set of pluggable django apps and ensuring templates degrade gracefully whether those apps exist in the environment or not?

[jj0hns0n]

Rob, the goal is to get rid of submodules entirely. geonode-client and
geonode-integration have already been moved directly into the repo in
the dev branch. Of course geonode-client is pulling in submodules, but
I dont see us getting away from that very easily.

This GNIP itself is only about the reorganization, but the layout does
indicate the proposed layout for template projects and django apps
that is described more in GNIP 7. But yes, the goal that you should be
able to use a minimal amount of pluggable apps if desired, and not
have any problems with the templates etc. I.e. the minimal amount of
reliance between apps as is necessary to do what is needed, and a
clear statement of which ones rely on others.

On Tue, Jun 5, 2012 at 11:04 AM, Robert Marianski
[email protected]
wrote:

Generally speaking, I'd prefer not to use submodules to include other repos, and instead rely on something like build automation to setup development environments.

In terms of scope, if it's just a matter of moving things around I'm +1 for reorganizations that make sense. But just to make sure I understand things correctly, does this gnip also include creating a set of pluggable django apps and ensuring templates degrade gracefully whether those apps exist in the environment or not?

---

Reply to this email directly or view it on GitHub:
#260 (comment)

[rmarianski]

Thanks for clarifying. Sounds good to me.

[dwins]

It probably makes sense to minimize scope for this GNIP by not including "making apps pluggable" as part of it. We can raise "foo is not pluggable" issues later as the need arises.

[jj0hns0n]

David, not sure where you want this change made? I've indicated in the
proposed layout which ones are intended to be the result of other
GNIPs and are not required now, but are only indicative so that they
are 'considered' now as we make this change.

On Tue, Jun 5, 2012 at 12:04 PM, David Winslow
[email protected]
wrote:

It probably makes sense to minimize scope for this GNIP by not including "making apps pluggable" as part of it.  We can raise "foo is not pluggable" issues later as the need arises.

---

Reply to this email directly or view it on GitHub:
#260 (comment)

[dwins]

As far as I could tell, it's not a change so much as a clarification. The proposal to reorganize the repo should just be moving things around and updating the build scripts to accommodate. "reorganizing" the code should not involve modifying it.

[jj0hns0n]

Agreed. This should simply be a series of git mv commands and as you
say updating the build and other scripts to handle for that. I dont
see anything about 'pluggables' in that GNIP page which is what I was
asking about. There is some indication about where those things would
live in the repo per other GNIPs, but it is strictly indicative.

On Tue, Jun 5, 2012 at 12:13 PM, David Winslow
[email protected]
wrote:

As far as I could tell, it's not a change so much as a clarification.  The proposal to reorganize the repo should just be moving things around and updating the build scripts to accommodate.  "reorganizing" the code should not involve modifying it.

---

Reply to this email directly or view it on GitHub:
#260 (comment)

[jj0hns0n]

This is complete in dev, closing