Skip to content

Migrate FuseArgs away from using Optparse #24

Description

@lonetwin

The current implementation of FuseArgs extends Optparse, which is scheduled to be deprecated in favor of argparse. Although there isn't a schedule for when it would be deprecated, it might be a good idea to reimplement this using argparse.

Furthermore, imho, the current implementation is a bit unwieldy and inflexible. For instance, I have spent way too longer than I expected and yet have not been able to figure out how to implement the command line to support something like:

my_fuse_cmd.py <required parameter> <required path parameter> <mountpoint> [fuse options]

If there is interest in migrating away from optparse, and nobody is already working on it, I would like to attempt doing this.

If it is felt that this isn't a worthwhile effort for any reason, could someone guide me on how to create a Fuse instance such that the command-line above is supported (using FuseArgs, that is -- I obviously could split up the parsing of args I am interested in and those that get passed to the parent Fuse class ...but that would be ugly).

Activity

  1. sdelafond commented on Jan 18, 2021

    @sdelafond
    Collaborator

    @lonetwin this would totally be worthwhile, and I'd gladly accept a PR for it.

  2. lonetwin commented on Jan 24, 2021

    @lonetwin
    Author

    @sdelafond I'm happy to start working on this. However, I was wondering whether this project intents to retain python 2.x support (afaict, 2.7 is still being supported according to the package classifiers in setup.py)

  3. sdelafond commented on Jan 25, 2021

    @sdelafond
    Collaborator

    Yes, I'd like to retain 2.x compatibility.

  4. lonetwin commented on Mar 29, 2025

    @lonetwin
    Author

    About 4 years after I initially request this, I am returning to actually implement it :).

    I've submitted PR #95 to address this. The PR is split into distinct commits:

    • The first that introduces the tests, without any modification to the code.
    • The second that migrates the code, without any modification to the tests.

    This ensures that we maintain compatibility with current usage. I could break these into 2 separate PRs if that would be easier to review / track.

    Note that I haven't really checked for compatibility with python 2.x as requested in the last comment and tbh, I am not very motivated to do this. If however, this is going to be a deal-breaker to get it merged, depending on whether the PR itself looks good, I'll attempt it (hopefully before another 4 yrs :) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions