[GeoNode-devel] Calling the cops on the party in geonode.contrib
ortelius at gmail.com
Mon Jul 20 06:27:06 PDT 2015
Paolo do you want to take a crack at doing this with the current
codebase? Might make sense to do a quick survey of other django
projects and see how else this is done and try to follow best
On Mon, Jul 20, 2015 at 6:06 AM, Paolo Corti <pcorti at gmail.com> wrote:
> Regarding the settings specific to a contrib application, I think they
> should live in a settings.py file for the given application.
> Therefore, if myapp contains the settings MYAPP_SETTING1,
> MYAPPING_SETTING2, I believe they should be contained in the
> myapp/settings.py file, and we should import this settings file from
> the main settings file only in case myapp is enabled (maybe via a
> MYAPP_ENABLED setting in the main settings file)
> We should also teach sphinx to build the documentation for each
> contrib application from the README app file.
> On Thu, Jul 16, 2015 at 5:48 PM, Jeffrey Johnson <ortelius at gmail.com> wrote:
>> Hi All,
>> I just pushed a commit directly to master that broke the build.
>> This puts the geonode.contrib apps in GEONODE_CONTRIB_APPS in
>> settings.py and makes sure they are *always* disabled by default.
>> The test failure is here
>> And the root cause is here
>> No need to point fingers as this PR went through the process we have
>> setup and was merged. We do however need to have some more guidelines
>> about how contrib modules should be handled.
>> After a quick chat with Simone and Ariel, I propose the following:
>> * New contrib modules should be initially proposed as a GNIP and
>> brought up on the list before submitting a PR
>> * Contrib modules should go into the GEONODE_CONTRIB_APPS block in
>> settings and _never_ be enabled by default.
>> * Contrib modules should have their own requirements.txt and not add
>> things to setup.py
>> * Contrib modules should be verified to not break the build when
>> enabled/disabled before merging
>> * There should be minimal docs about what it does and how to use it
>> etc. A README in the module is sufficient, a page in docs/
>> Anything else I missed? Im +1 to keep the party going and looking
>> forward to seeing interesting things in this part of the codebase, but
>> we cant get sloppy.
>> geonode-devel mailing list
>> geonode-devel at lists.osgeo.org
> Paolo Corti
> Geospatial software developer
> web: http://www.paolocorti.net
> twitter: @capooti
> skype: capooti
More information about the geonode-devel