Moving gcloud.bigtable.happybase into third_party/

[theacodes]

Towards #1762

This technically works, but some things to note:

• python setup.py develop and by extension pip install -e do not respect the package_dir argument to setup, as such, gcloud.bigtable.happybase will not be available if it's installed that way.
• Not sure how the tests/docs will react to this, @dhermes, let me know your thoughts.

Don't merge until we get confirmation from OSPO that this is the correct thing to do.

[theacodes]

The only alternative I can think of is symlinking, and I'm not sure how I feel about that.

[theacodes]

Another alternative is just making this a separate, optional package gcloud-happybase, which might be cleaner.

[theacodes]

/cc @jgeewax @tseaver

[dhermes]

Thanks for taking this on. Both test failures seem to indicate that the imports fail. I'm also curious about the contents of the zip created for the distribution.

[theacodes]

Both test failures seem to indicate that the imports fail.

Yeah this is weird. I pip installed this locally and I can import, but as I meanted setup.py develop doesn't work so it may be how tox handles installing the package.

I'm starting to think that moving this into a separate library is the best way to go.

[dhermes]

I'm fine with gcloud-happybase. @jgeewax WDYT?

[tseaver]

FWIW, the code this PR moves into third_party/happybase is not really "third-party" code (i.e., as if we had vendored in happybase): it is (or is claimed to be) a derived work from third-party code, and hence we need to mention that code's license.

I'm not sure that moving it does anything to help the legalities, compared to just having the header comments mention the separate license (which could just be tacked onto the current LICENSE file with a note).

[theacodes]

This is what our open-source laywers have told us to do. It's best to
follow their guidance in these situations. It needs to live in third party
and be under the original projects license, regardless of how we publish it.

On Fri, May 6, 2016, 4:09 PM Tres Seaver [email protected] wrote:

FWIW, the code this PR moves into third_party/happybase is not really
"third-party" code (i.e., as if we had vendored in happybase): it is (or
is claimed to be) a derived work from third-party code, and hence we need
to mention that code's license.

I'm not sure that moving it does anything to help the legalities, compared
to just having the header comments mention the separate license (which
could just be tacked onto the current LICENSE file with a note).

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1777 (comment)

[dhermes]

@jonparrott Why the close?

[theacodes]

Because this approach won't work.

[dhermes]

OK