Skip to content

Make configure_command easier to call and comment about MSYS #1592

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

Merged
merged 3 commits into from
Sep 11, 2024

Conversation

EliahKagan
Copy link
Member

@EliahKagan EliahKagan commented Sep 11, 2024

No major design changes along the lines discussed in #1578 seemed like a decisive improvement; all of them had significant disadvantages. This instead:

  • Makes configure_command take anything we can iterate to get arguments, rather than requiring a &[String]. This makes the current test simpler and easier to read, and should also help with future tests.
  • Comments about how we don't heed env and env_remove calls on the Command object where "MSYS" is the key, since we take it from our environment directly and modify that.

There's slightly more thoughts in the commit messages. Also, I had trouble articulating why I thought 0e1e6a9 might be better here, since I don't usually prefer the more compact style, so maybe it's better without that change.

This makes the private `gix_testtools::configure_command` function
generic (in type as well as lifetime) to accept anything as `args`
that the `args` method of `std::process::Command` accepts.

This also uses the broader parameter type to simplify a test.
I'm not sure if this is better, but the new genericity distracts
less from what the function is really about when prsented this way.
This problem can be avoided by a design that doesn't create the
assumption that such calls would have an effect, or that prevents
them from being made (e.g. a builder funtion), or by accounting for
and honoring them (which may involve reimplementing a fragment of
the Windows API based case-folding that `std::process::Command`
uses). But none of these approaches really seems overall better
than what we are doing now. So for now, keep the design but note
this one confusing spot.

This is a private function, so I've just commented by where the
relevant logic is, rather than using a `///` comment.
Copy link
Member

@Byron Byron left a comment

Choose a reason for hiding this comment

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

Definitely an improvement, very nice, thank you!

@Byron Byron merged commit 5e783de into GitoxideLabs:main Sep 11, 2024
15 checks passed
@EliahKagan EliahKagan deleted the tools-cfgcmd branch September 11, 2024 11:20
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.

2 participants