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

Fix the testutil wheel's imports not working due to namespace packages #10725

Merged
merged 3 commits into from Sep 3, 2020

Conversation

Eric-Arellano
Copy link
Contributor

Imports stopped working for testutil in 2.0.0.dev2 because we removed the line __import__("pkg_resources").declare_namespace(__name__) from src/python/pants/__init__.py, so we were no longer using namespace packages and we had two dists with the same namespace.

This PR also fixes the setup-py goal to error if users are manually setting namespace_packages and install_requires. Pants manages that for users. Before, we were silently overwriting values they set, which was confusing.

[ci skip-rust]
[ci skip-build-wheels]

@@ -116,7 +116,7 @@ function pkg_testutil_install_test() {
shift
local PIP_ARGS=("$@")
pip install "${PIP_ARGS[@]}" "pantsbuild.pants.testutil==${version}" && \
python -c "import pants.testutil"
python -c "import pants.testutil.option_util"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This doesn't actually trigger an error on the master branch, for some reason. It imports just fine. I'm not sure why or how to reproduce in release.sh, even though I reproduce everywhere else like running pex testutil==2.0.0a1 then import pants.testutil.option_util.

@@ -25,7 +25,6 @@ python_distribution(
provides=setup_py(
name='pantsbuild.pants',
description='A scalable build tool for large, complex, heterogeneous repos.',
namespace_packages=['pants', 'pants.backend'],
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure why we were declaring pants.backend. That is inferred due to pants, afaict.

@@ -0,0 +1 @@
__import__("pkg_resources").declare_namespace(__name__)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I considered also adding this to pants/testutil/__init__.py, but I don't think it's necessary. We didn't have that declaration before, and testutil worked. I think we only need it at the top level.

Copy link
Sponsor Contributor

Choose a reason for hiding this comment

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

We only need it in packages that are shared across multiple dists/source roots, so yeah.

Copy link
Sponsor Contributor

Choose a reason for hiding this comment

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

Might be worth adding a comment that this is necessary because we build two wheels under this source root. Otherwise a naive reader might wonder why it's necessary to have this when pants is defined only under this single source root.

Comment on lines -203 to +210
for arg in {"data_files", "package_dir", "package_data", "packages"}:
for arg in {
"data_files",
"namespace_packages",
"package_dir",
"package_data",
"packages",
"install_requires",
}:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alternatively, we could allow users to set some of these and have us extend the values, rather than overwriting like we were doing.

I think I err on the side of banning, though. As a user, if I set namespace_packages=['foo'], I think I would be confused if Pants ended up adding two additional values to it. It's not clear that Pants auto-magically sets these 6 values, but it doesn't touch any other kwargs.

If we get user feedback that they really need to set these, we can add a safety valve. (Actually, that safety valve already exists. They can use a custom SetupKwargs implementation and in the constructor to SetupKwargs, set the arg _allow_banned_keys=True.

Copy link
Sponsor Contributor

Choose a reason for hiding this comment

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

Would that work, since we overwrite? Wouldn't we have to check if the value exists and only write it if not?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Would that work, since we overwrite? Wouldn't we have to check if the value exists and only write it if not?

Ah, true. I can fix that, though, if you think it's a good idea?

That would mean that by default, you can't set those values because it would be too confusing. But if you really want a safety valve, you have it.

Copy link
Sponsor Contributor

Choose a reason for hiding this comment

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

Yes, exactly. With a comment explaining that :)

This ensures that things stay stable across Python versions. Python 3.8 added Pickle 5, but we can't use that for Python 3.6 and 3.7

# Rust tests and lints will be skipped. Delete if not intended.
[ci skip-rust]

# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
* Add comment about check_inits.py
* Fix the precommit hook
* Fix setup_py.py to not override those 6 values, and explain why we do that

# Rust tests and lints will be skipped. Delete if not intended.
[ci skip-rust]

# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
@Eric-Arellano Eric-Arellano merged commit e65cbf9 into pantsbuild:master Sep 3, 2020
@Eric-Arellano Eric-Arellano deleted the fix-testutil branch September 3, 2020 01:41
@coveralls
Copy link

Coverage Status

Coverage remained the same at 0.0% when pulling 2793b4d on Eric-Arellano:fix-testutil into a0a98af on pantsbuild:master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants