Excluding system tests from being installed.

[dhermes]

@tseaver I noticed this while trying to from system_tests import populate_datastore and the import failed due to reasons that were "resolved" in #1349.

Then I peaked and realized that the error was coming from

/usr/local/lib/python2.7/dist-packages/system_tests/populate_datastore.py
/usr/local/lib/python2.7/dist-packages/gcloud/datastore/client.py

Notice that in our repo:

>>>fromsetuptoolsimportfind_packages>>>find_packages()
['gcloud',
'system_tests',
'gcloud.storage',
'gcloud.pubsub',
'gcloud.dns',
'gcloud.bigtable',
'gcloud.bigquery',
'gcloud.resource_manager',
'gcloud.search',
'gcloud.datastore',
'gcloud.streaming',
'gcloud.storage.demo',
'gcloud.bigtable.happybase',
'gcloud.bigtable._generated',
'gcloud.datastore.demo',
'gcloud.datastore._generated']

(This is due to the fact that system_tests/__init__.py was added in #954 / #273)

[tseaver]

Note that excluding in MANIFEST.in will exclude them from the sdist, which can make it hard for downstreams to test (if that matters).

On what host were those /usr/local/lib/python2.7/dist-lib/ paths found?

[dhermes]

Ubuntu 14.04

[dhermes]

@tseaver PTAL. I did a hacky thing my modifying sys.path in __main__.

[tseaver]

We still don't want to ship /usr/local/lib/python2.7/dist-packages/system_tests/ to people

You mean we don't want those files to be there after they run sudo pip install gcloud? I'm thinking of downstream packagers, who might want to be able to run all the tests after creating a .deb/.rpm from the sdist.

[dhermes]

You mean we don't want those files to be there after they run sudo pip install gcloud

Yep. Is there a middle ground?

[dhermes]

@tseaver Bump

[dhermes]

@tseaver Bump

[dhermes]

@tseaver PTAL

[tseaver]

I'm still against stripping the system tests from the sdist. Can we move the importable support code into a subpackage of gcloud, and just keep system_tests off the PYTHONPATH?

[dhermes]

Why do we want to ship our system tests?

[tseaver]

So that downstream packagers (e.g., .deb/.rpm) can run them to verify they have working code?

[dhermes]

Our system tests? These require a ton of set-up, including having to go to the Cloud Console and download a key.

[tseaver]

I've gotten feedback from .deb/.rpm maintainers in the past that they wanted to be able to verify the working state of the code they package by running tests afterward. Maybe they wouldn't run the system tests.

OTOH, as the APIs change over time, asking users to run them to help debug configuration issues vs. software might be reasonable.

[dhermes]

It's not like git clone is difficult for the .deb/.rpm maintainers, or for users that are able to offer useful help

[dhermes]

@tseaver WDYT of my comment above?

[theacodes]

LGTM, on the basis that gcloud isn't the type of library we would expect to see as an OS-level dependency. Nor do I think it's a good idea to pursue that path, as it would hold our releases and support subject to OS release cycles (which are generally very slow).

[dhermes]

Filed #1451 for discussion of the possibility to ship the system tests as gcloud.system_tests. Merging for now.