search

PyBites-Open-Source / eatlocal

This package helps users solve PyBites code challenges on their local machine.
MIT License
20 stars 9 forks source link

Feature: refactor command-line interface #10

Closed JnyJny closed 2 years ago

JnyJny commented 2 years ago

Download changed:

OLD $ eatlocal -d <bite>
NEW $ eatlocal download <bite>

Submit changed:

OLD $ eatlocal -s <bite>
NEW $ eatlocal submit <bite>

Removed the standalone extract command-line option.

Download operation now:

These changes required re-organizing the __main__.py functions, specifically breaking out all the option processing in the main() function into their own specific subcommands.

The global_options function is a typer callback that is invoked before any of the other subcommand decorated functions, making it a good place to take care of global options that are used by the subcommands. In this particular case, it's the credentials for PyBites obtained from the environment. The credentials are passed to subcommands via the typer.Context automatic argument, specifically the ctx.obj attribute which can be any object. I created a namedtuple called GlobalOptions with a single member creds which is a tuple of username and password strings.

While the user must type a little more, e.g. download vs -d, the code is much simplier and it will be easier to extend this utility when new functionality is identified.

JnyJny commented 2 years ago

Addresses #9

rhelmstedter commented 2 years ago

Checking my understanding here... By getting rid of the stand alone command-line option extract that means people will have to extract an already downloaded bite using some other tool, correct?

JnyJny commented 2 years ago

That's true, however most operating systems ship with a zip archive utility; typically called zip/unzip. What are the scenarios where you would want a stand-alone extract command?

The first two can be solved with git checkout -- <bite> if the bite was checked in (something we can automate) or by removing the bite directory and re-downloading the bite.

I think having download check for the existence of a zip archive before trying to download would solve the extract problem. We could cache zips in a directory of the repo to speed up that operation (and making keep_zip=True the default behavior).

rhelmstedter commented 2 years ago

My thought was I like the tool being able to deal with all things bite related. If someone has a bite already downloaded, they could extract it using the tool. But maybe I'm holding just holding on to original original workflow that this was designed to improve.

I think having download check for the existence of a zip archive before trying to download would solve the extract problem. We could cache zips in a directory of the repo to speed up that operation (and making keep_zip=True the default behavior).

I like that idea. Should I merge this pull first or hold off?

JnyJny commented 2 years ago

I would say merge this PR (of course I would) since it provides a scaffold for the rest of the work (caching).

rhelmstedter commented 2 years ago

Haha! You would to merge the pull request you made? That is odd.