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

Make _danger-local-https feature additive #430

Merged
merged 1 commit into from
Dec 29, 2024

Conversation

DanGould
Copy link
Contributor

@DanGould DanGould commented Dec 4, 2024

See: https://doc.rust-lang.org/cargo/reference/features.html#feature-unification

"Rust features should be additive. That is, enabling a feature should not disable functionality, and it should usually be safe to enable any combination of features"

Before this change io::fetch_ohttp_keys changed its signature based on the feature flag. I noticed downstream that this creates a feature flag mess in bindings and it's one opportunity to address tech debt.

This begins to address #392

@DanGould DanGould force-pushed the additive-danger-local-https branch from 6b17604 to 05d0406 Compare December 4, 2024 20:01
@coveralls
Copy link
Collaborator

coveralls commented Dec 4, 2024

Pull Request Test Coverage Report for Build 12537462995

Details

  • 7 of 16 (43.75%) changed or added relevant lines in 2 files are covered.
  • 24 unchanged lines in 5 files lost coverage.
  • Overall coverage decreased (-0.4%) to 61.384%

Changes Missing Coverage Covered Lines Changed/Added Lines %
payjoin/src/io.rs 7 11 63.64%
payjoin-cli/src/app/v2.rs 0 5 0.0%
Files with Coverage Reduction New Missed Lines %
payjoin/src/receive/error.rs 1 1.46%
payjoin/src/send/mod.rs 2 92.5%
payjoin/src/receive/mod.rs 5 90.31%
payjoin/src/psbt.rs 7 46.56%
payjoin/src/io.rs 9 36.17%
Totals Coverage Status
Change from base Build 12528252226: -0.4%
Covered Lines: 2882
Relevant Lines: 4695

💛 - Coveralls

@DanGould DanGould marked this pull request as draft December 4, 2024 20:04
@DanGould DanGould force-pushed the additive-danger-local-https branch 3 times, most recently from 5e87fe5 to 580a92a Compare December 27, 2024 02:55
@DanGould DanGould marked this pull request as ready for review December 27, 2024 02:57
@DanGould DanGould requested a review from nothingmuch December 27, 2024 02:57
Copy link
Collaborator

@nothingmuch nothingmuch left a comment

Choose a reason for hiding this comment

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

the code change looks reasonable, but am missing the correspondence between these changes and the following:

Before this change io::fetch_ohttp_keys changed its signature based
on the feature flag. I noticed downstream that this creates a feature
flag mess in bindings and it's one opportunity to address tech debt.

does this just boil down to splitting things so instead of a cfg gated argument to a fn it's a cfg gated fn? if so, then ACK, but if not then i misunderstood something. either way explicitly describing the problem that existed before this commit would be helpful, as "a flag mess in the bindings" is a bit vague

@DanGould
Copy link
Contributor Author

does this just boil down to splitting things so instead of a cfg gated argument to a fn it's a cfg gated fn?

It does.

A flag mess in the bindings meant that we needed to have switched function signatures downstream as well. Do you need me to change the commit message?

@DanGould DanGould force-pushed the additive-danger-local-https branch from 580a92a to fdd1117 Compare December 28, 2024 17:11
@DanGould DanGould requested a review from nothingmuch December 29, 2024 16:59
@nothingmuch
Copy link
Collaborator

A flag mess in the bindings meant that we needed to have switched function signatures downstream as well. Do you need me to change the commit message?

oops missed this, thanks for re-requesting review.

i see... i don't think it matters much to change the commit message, it helps me to understand in this case, and in general that's a good thing for commit messages to have, but i also doubt this particular explanation will be very meaningful to anyone reviewing the history in hindsight. i'm ACK, but feel free to do that if for extra cookie points ;-)

Instead of feature gating function params, which introduces the need for
similar feature gating in downstream code, feature gate individual
functions.

See: <https://doc.rust-lang.org/cargo/reference/features.html#feature-unification>

"Rust features should be *additive*. That is, enabling a feature should
not disable functionality, and it should usually be safe to enable any
combination of features"

Before this change `io::fetch_ohttp_keys` had two function signatures
and changed its signature based on the feature flag. I noticed downstream
that this creates a necessity to carry those flags mess into bindings
or else face compile issues under certain feature combinations.

`io` now enables the `v2` feature since it only contains methods for
fetching OHTTP keys which is only useful in V2. In the future perhaps
it will also include generic HTTP client behavior taking `Request` as
a parameter in which case it should not enable `v2`, because such
functionality would be useful in a V1 setting as well.
@DanGould DanGould force-pushed the additive-danger-local-https branch from fdd1117 to fdcc566 Compare December 29, 2024 17:39
@DanGould DanGould merged commit b4a4b03 into payjoin:master Dec 29, 2024
6 checks passed
DanGould added a commit that referenced this pull request Jan 2, 2025
#430 made some features additive, but didn't properly address the tests
to run under the minimal requirements nor the scripts to run the tests.

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

Successfully merging this pull request may close these issues.

3 participants