NASA-DEVELOP/dnppy

Travis-CI needs access to all dependencies, and arcpy is proprietary.

Closed this issue · 7 comments

Jwely commented

Issue

We should have seen this issue coming, but we've now hit the stage where we'd like to run autmodule on all dnppy functions and classes, and this process cannot run successfully on travis-ci without giving it some way to handle import arcpy.

Potential solutions

  • Do not use autmodule on functions with arcpy dependencies. Mixing manual and automatic documentation.
  • Somehow fake an arcpy import for the sake of travis-ci to get around that step.
  • Switch to a documentation update strategy that requires us to build locally and commit to gh-pages

I think I can write a hacky workaround for this using the mock library

Jwely commented

There is a pretty decent thread on mock at stack-overlfow.

In the meantime, I've started to go through and remove a few arcpy dependencies. This has been a long term goal of ours anyways, might as well get started.

Nice find, if you run into some modules you can't remove the arcpy dependency for you can always commit those modules that cause the error and I can try and fix them.

I'm also working on getting the travis-sphinx to detect sphinx build warnings (like misspelling modules). The problem is the exceptions thrown for stuff like this are already handled by sphinx meaning I can't catch them myself and have no way to detect them. There is a solution out there I just need to find one

build warnings should result in an error not a successful build , so although the docs are technically passing I want to make the requirements for a build to pass much more strict

EDIT: Got it, warnings will now result in errors

Jwely commented

I usually review the logs at https://travis-ci.org/NASA-DEVELOP/dnppy after a build, but since technically all the issues I've been having are warnings and not errors, it does technically achieve a build passing. It doesn't really hurt anything to finish the build even with warnings, it just means its a good idea to check out the logs from time to time and verify no errors are present.

The download module page works now, there was only one arcpy call and I was able to slide gdal in there pretty easily. This has prompted me to take a better inventory of all the arcpy calls, which I've been meaning to do anyway.

Jwely commented

I've got it. Running this script:

    def module_mock(module):
        """ attempts to import a module, mocks it upon exception """ 
        try:
            return __import__(module)

        except ImportError:
            print("{0} is being mocked!".format(module))
            import mock
            return mock.MagicMock()

    arcpoops = module_mock("arcpoops")

    output = arcpoops.function("args")
    print(output)

Will produce the following output

>>> arcpoops is being mocked!
>>> <MagicMock name='mock.function()' id='46754480'>

I just need to place a function like this inside the core module, and replace all 27 remaining occurrences of import arcpy with something like

from core import module_mock
arcpy = module_mock("arcpy")

Unless we can think of an even simpler way to do it?

I believe you can abstract this so it won't actually modify your existing codebase, see this link

Jwely commented

That was definitely simpler. All module import related issues for travis-ci are now fixed.