Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moving core into designated package. #2367

Merged
merged 7 commits into from
Sep 23, 2016

Conversation

dhermes
Copy link
Contributor

@dhermes dhermes commented Sep 20, 2016

This is a tiny chunk of #2357 that should be easier to review and discuss.

Still missing (per discussion with @jonparrott):

  • Putting unit tests into the core subdirectory
  • A better story for isolating packages / making sure the proper dependencies are listed (may have to have core/tox.ini and run that separately, though this will become too slow, so maybe we'll switch to using nox)

NOTE: Has #2394 as diffbase.

@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Sep 20, 2016
@@ -0,0 +1,58 @@
import os

This comment was marked as spam.

This comment was marked as spam.


PACKAGE_ROOT = os.path.abspath(os.path.dirname(__file__))

with open(os.path.join(PACKAGE_ROOT, 'README.rst')) as file_obj:

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

REQUIREMENTS = [
'httplib2 >= 0.9.1',
'googleapis-common-protos',
'oauth2client >= 2.0.1',

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

@theacodes
Copy link
Contributor

@dhermes do you want to try to address those still missing items in this PR or another?

@dhermes
Copy link
Contributor Author

dhermes commented Sep 20, 2016

do you want to try to address those still missing items in this PR or another?

I'd like to iron out the strategy during this PR and I'd love to hear from @tseaver.

@dhermes
Copy link
Contributor Author

dhermes commented Sep 20, 2016

FYI I folded the license header change and the upper bound for oauth2client into the original commit.

@theacodes
Copy link
Contributor

For the tests, I would suggest:

  1. Move them into the core folder under tests
  2. Be sure to update the manifest.in and such.
  3. Make a core/tox.ini for the time being.

Even if you decide to use nox to automate across the packages, you can still use tox within each package. The sample I sent you earlier does just that (nox is top-level, but nox just shells out to tox for each sub-folder).

@dhermes
Copy link
Contributor Author

dhermes commented Sep 20, 2016

D'oh! Forgot MANIFEST.in!

@dhermes
Copy link
Contributor Author

dhermes commented Sep 21, 2016

@tseaver @jonparrott Isolating core with its own tox.ini has revealed that our user agent code has to change from what it is today. Right now it depends on the version (via get_distribution) of google-cloud. This is problematic, since we are going to a future where users don't even need to have the umbrella package installed.

@dhermes
Copy link
Contributor Author

dhermes commented Sep 21, 2016

PTAL. I created a tox config in the core subdirectory.


No longer true:

Though right now tox -e cover is failing on the umbrella because it isn't picking up the moved unit tests.

@jonparrott Any suggestions for how to pick them up?

- tox -e lint
- tox -e cover
- cd core && tox -e cover
- (cd core && tox -e cover)

This comment was marked as spam.

This comment was marked as spam.

@@ -0,0 +1,3 @@
include README.rst
graft google
global-exclude *.pyc

This comment was marked as spam.

This comment was marked as spam.

Copy link
Contributor

@tseaver tseaver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really uncomfortable with where the core subdirectory change is going: it is causing us to replicate files / testing logic, etc. all over the place.

Could we avoid that, and have separate files in the root, instead? E.g. setup_core.py, tox-core.ini, README-core.py, etc.

@@ -6,8 +6,6 @@ omit =
*/_generated/*.py
# Packages in the "google.cloud" package that we don't own.
*/google/cloud/gapic/*
fail_under = 100
show_missing = True

This comment was marked as spam.

This comment was marked as spam.

- tox -e lint
- tox -e cover
- (cd core && tox -e cover)

This comment was marked as spam.

This comment was marked as spam.

@@ -28,7 +28,7 @@
"""The base of the API call URL."""

DEFAULT_USER_AGENT = 'gcloud-python/{0}'.format(
get_distribution('google-cloud').version)
get_distribution('google-cloud-core').version)

This comment was marked as spam.

@theacodes
Copy link
Contributor

theacodes commented Sep 21, 2016

Could we avoid that, and have separate files in the root, instead? E.g. setup_core.py, tox-core.ini, README-core.py, etc.

@tseaver how does that avoid duplication? That only makes things more complicated because the package-specific setup.py and manifest will have to go out of its way to exclude the other packages. It also breaks the convention of python setup.py install and pip install .

@dhermes
Copy link
Contributor Author

dhermes commented Sep 22, 2016

@tseaver Regarding duplication, these are the things right now that are being duplicated

  • MANIFEST.in
  • Majority of setup.py
  • Some __init__.py and directory structure (both in unit_tests/ and in google/)
  • unit_tests/_testing.py is mostly duplicated, though as of right now, _Monkey is the only piece used by the core subpackage and mock.patch() can handle _Monkey's job just fine

The setup.py and __init__.py / structure duplication are unavoidable. However, the rest aren't really duplication at a certain point, e.g. MANIFEST.in may very well contain different things for each subpackage.


As far as the isolation, you even see with some of the commits in this PR that putting core on its own revealed some missing code paths in the core unit tests.

This way we can be sure what each subpackage depends on and what needs to be tested for users that don't install the umbrella package.

@dhermes dhermes force-pushed the make-core-subpackage branch 2 times, most recently from f9a8a5c to b950f8f Compare September 22, 2016 19:29
@@ -37,6 +37,8 @@
]
IGNORED_FILES = [
os.path.join('docs', 'conf.py'),
os.path.join('google', '__init__.py'),
os.path.join('google', 'cloud', '__init__.py'),

This comment was marked as spam.


setup(
name='google-cloud-core',
version='0.19.0',

This comment was marked as spam.

'Programming Language :: Python :: 3.5',
'Topic :: Internet',
],
}

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.


def __exit__(self, exc_type, exc_val, exc_tb):
import os
os.remove(self.name)

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

--cov-append \
--cov-config {toxinidir}/.coveragerc \
core/unit_tests
coverage report --show-missing --fail-under=100

This comment was marked as spam.

This comment was marked as spam.

Only files have been moved for now. Will be made into a proper
package shortly.

Done via:

$ mkdir -p core/google/cloud/streaming
$ cp google/__init__.py core/google/__init__.py
$ git add core/google/__init__.py
$ cp google/cloud/__init__.py core/google/cloud/__init__.py
$ git add core/google/cloud/__init__.py
$ git mv google/cloud/_helpers.py core/google/cloud/_helpers.py
$ git mv google/cloud/_testing.py core/google/cloud/_testing.py
$ git mv google/cloud/client.py core/google/cloud/client.py
$ git mv google/cloud/connection.py core/google/cloud/connection.py
$ git mv google/cloud/credentials.py core/google/cloud/credentials.py
$ git mv google/cloud/environment_vars.py core/google/cloud/environment_vars.py
$ git mv google/cloud/exceptions.py core/google/cloud/exceptions.py
$ git mv google/cloud/iterator.py core/google/cloud/iterator.py
$ git mv google/cloud/operation.py core/google/cloud/operation.py
$ git mv google/cloud/streaming/__init__.py core/google/cloud/streaming/__init__.py
$ git mv google/cloud/streaming/buffered_stream.py core/google/cloud/streaming/buffered_stream.py
$ git mv google/cloud/streaming/exceptions.py core/google/cloud/streaming/exceptions.py
$ git mv google/cloud/streaming/http_wrapper.py core/google/cloud/streaming/http_wrapper.py
$ git mv google/cloud/streaming/stream_slice.py core/google/cloud/streaming/stream_slice.py
$ git mv google/cloud/streaming/transfer.py core/google/cloud/streaming/transfer.py
$ git mv google/cloud/streaming/util.py core/google/cloud/streaming/util.py
Also changing the version from 0.19.0 to 0.20.0dev.

Done by adding new setup.py, MANIFEST and README to core subdirectory,
adding core to the list of packages in verify_included_modules,
updating the umbrella setup to depend on core and adding the local
core package to the umbrella tox config.
Done via:

$ mkdir -p core/unit_tests/streaming
$ cp unit_tests/__init__.py core/unit_tests/__init__.py
$ git add core/unit_tests/__init__.py
$ cp unit_tests/streaming/__init__.py core/unit_tests/streaming/__init__.py
$ git add core/unit_tests/streaming/__init__.py
$ git mv unit_tests/test__helpers.py core/unit_tests/test__helpers.py
$ git mv unit_tests/test_client.py core/unit_tests/test_client.py
$ git mv unit_tests/test_connection.py core/unit_tests/test_connection.py
$ git mv unit_tests/test_credentials.py core/unit_tests/test_credentials.py
$ git mv unit_tests/test_exceptions.py core/unit_tests/test_exceptions.py
$ git mv unit_tests/test_iterator.py core/unit_tests/test_iterator.py
$ git mv unit_tests/test_operation.py core/unit_tests/test_operation.py
$ git mv unit_tests/streaming/test_buffered_stream.py core/unit_tests/streaming/test_buffered_stream.py
$ git mv unit_tests/streaming/test_exceptions.py core/unit_tests/streaming/test_exceptions.py
$ git mv unit_tests/streaming/test_http_wrapper.py core/unit_tests/streaming/test_http_wrapper.py
$ git mv unit_tests/streaming/test_stream_slice.py core/unit_tests/streaming/test_stream_slice.py
$ git mv unit_tests/streaming/test_transfer.py core/unit_tests/streaming/test_transfer.py
$ git mv unit_tests/streaming/test_util.py core/unit_tests/streaming/test_util.py
The coverage RC file for the core subpackage intentionally
leaves out google.cloud._testing. This is because the core tests
don't use the entire functionality of the _testing module, but
the umbrella package does.

By leaving the module in the google-cloud-core package, every
other package can depend on it and have the test helpers
ready to access.
This was necessary because some lines were only tested transitively
in the umbrella package, rather than directly by the core tests.
Also updating Travis config to incorporate core package.
@dhermes
Copy link
Contributor Author

dhermes commented Sep 23, 2016

@tseaver Rebased all the lower PRs so this is ready to go.

Any remaining issues that haven't been punted on? Do you want me to have a tracking issue for the remaining work:


Also @tseaver how do you feel about my manually making a core-0.20.0dev tag and then manually pushing google-cloud-core with twine? (I'd first need to turn off the Travis auto-upload feature, since it would push on any old tag.) This way I can move to Bigtable and then do a proper release of https://github.com/GoogleCloudPlatform/google-cloud-python-happybase before the entire package move is done.

@dhermes
Copy link
Contributor Author

dhermes commented Sep 23, 2016

@tseaver We are green after rebase, all systems go. PTAL.

@tseaver
Copy link
Contributor

tseaver commented Sep 23, 2016

@dhermes LGTM. One question: wouldn't we logically have different versions / tags for the different API libraries, separate from -core or the umbrella package?

@dhermes
Copy link
Contributor Author

dhermes commented Sep 23, 2016

@tseaver Yes. The idea was laid out here: https://github.com/GoogleCloudPlatform/gcloud-common/issues/138#issuecomment-220830613

I was thinking we'd get all packages at 0.20.0 and then increment them all on their own schedule from there.


UPDATE: As for the tags, I figured we'd have a script that literally parses the tag name for a tag build and then determines which package needs to be pushed in that tag release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes This human has signed the Contributor License Agreement. packaging
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants