Fix #24: Migrate FuseArgs away from using Optparse#95
Fix #24: Migrate FuseArgs away from using Optparse#95lonetwin wants to merge 4 commits intolibfuse:masterfrom
FuseArgs away from using Optparse#95Conversation
This is the first of a 3-patch series of commits to address libfuse#24 This commit introduces tests for the current `Optparse` based implementation to ensure that the next commit doesn't break current usage compatibility. The next commit would introduce the `ArgumentParser` based implementation. The final commit will attempt to do some minor clean up to make the code a bit more idomatic / pythonic.
This PR changes the `Optparse` based implementation to one base on `ArgumentParser` for `FuseArgs`, without touching the tests introduced in the previous commit. We delete the `subbedopts` sub-module and implemented all of the argument parsing/handling in the main Fuse/FuseArgs implementation.
|
The PR is split into distinct commits:
This ensures that we maintain backwards compatibility. I could break these into 2 separate PRs if that would be easier to review / track. |
lonetwin
changed the title
FuseArgs away from using Optparse
|
Seems like there's a bit more work left on this w.r.t parsing strings that have implicit arguments such as Aside: It might seem like we'd have to add some deprecation messages for code that relies on |
|
Thanks, that looks promising. Please fix the tests that fail to now start in the CI, and we'll then take it from there. |
|
@lonetwin can you please rebase on |
|
@sdelafond apologies for the delay. I'm assuming this is good to merge? |
What about your earlier comment regarding "a bit more work left on this w.r.t parsing strings that have implicit arguments such as %prog"? |
2 participants
This PR addresses #24. It replaces the
Optpasebased implementation ofFuseArgsto one based onArgumentParserand also adds some tests for the parsing functionality.