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

Add content_hashing feature flag #107

Merged

Conversation

elthariel
Copy link
Contributor

Fixes #106, by allowing to use the dependencies content hash instead of the $RULE_HASH as the pex stamp.

I don't think I properly understand the reasoning behind the use of RULE_HASH, but I still intuitively feels that using the rule hash instead of the content hash brings a quite weird user experience and that content_stamp=True might be a reasonable default ? WDYT ?

Also, I think the generated hash is a bit long. Maybe we could only take the last N characters of the hash ?

Copy link
Contributor

@samwestmoreland samwestmoreland left a comment

Choose a reason for hiding this comment

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

Hey, thanks for the pr! I think what you're saying makes sense.

Maybe we could put this behind a feature flag rather than adding a new argument to python_binary? That way we can enable it by default with the next major version as this will be a breaking change. There's an example in the go-rules plugin, where you can then access it in the build def with something like if "content_hash" in CONFIG.PYTHON.FEATURE_FLAGS....

Also do we need to add the lib_rule to the deps of the pex_rule? Maybe I'm missing something but they're not used by the pex_rule and they're added to the final binary as a dep. The hash will just be passed into the pex tool via the command line arg.

@elthariel
Copy link
Contributor Author

@samwestmoreland the dependency is necessary, because if not, the lib rule is not built, and its hash isn't available. But if you have a nicer option, feel free to share it :)

Also, the feature flag seems like a great idea, thanks. Do you have any pointer about how the feature flags thing work ? I haven't encountered this construst yet. If you think this is a straightforward thing, I'll have a look at the code code to figure it out

@elthariel elthariel force-pushed the feat-pex-content-stamp branch from 5323bbe to e155691 Compare April 7, 2023 09:05
@elthariel
Copy link
Contributor Author

I think I've implemented it the way you suggested ?

I could not find any reference of the WheelHashing feature flag anywhere, so I removed it. Was I right ?

@elthariel elthariel changed the title Add content_stamp flag to python_binary Add content_hashing feature flag Apr 7, 2023
@samwestmoreland
Copy link
Contributor

Thanks for the changes, @elthariel. Yeap the wheelhashing feature flag can be removed, and everything else looks good, thanks!

@samwestmoreland samwestmoreland merged commit 6629da9 into please-build:master Apr 11, 2023
samwestmoreland pushed a commit to samwestmoreland/python-rules that referenced this pull request Apr 11, 2023
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.

pex files with different content gets same stamp
2 participants