[GeoNode-devel] Calling the cops on the party in geonode.contrib

Paolo Corti pcorti at gmail.com
Mon Jul 20 06:47:25 PDT 2015


Sure, I will try to see how this is handled in other projects and get
back with some more considerations
cheers
p

On Mon, Jul 20, 2015 at 3:27 PM, Jeffrey Johnson <ortelius at gmail.com> wrote:
> 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
> practices.
>
> 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.
>>
>> cheers
>> p
>>
>> 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.
>>> https://github.com/GeoNode/geonode/commit/4baca0a24b65b9a2c656c47fd54c8c2f1c794acb
>>>
>>> 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
>>> https://travis-ci.org/GeoNode/geonode/builds/71270871#L1645
>>>
>>> And the root cause is here
>>>
>>> https://github.com/GeoNode/geonode/pull/2206/files#diff-33cf4fcb0f4b5b8bf97b2d580c7eaec1R81
>>>
>>> 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.
>>>
>>> Jeff
>>> _______________________________________________
>>> geonode-devel mailing list
>>> geonode-devel at lists.osgeo.org
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/geonode-devel
>>
>>
>>
>> --
>> Paolo Corti
>> Geospatial software developer
>> web: http://www.paolocorti.net
>> twitter: @capooti
>> skype: capooti



-- 
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti


More information about the geonode-devel mailing list