[yeti-sh]

That's right; Google also published a similar package named `fire`, I used it a lot.

> just `python your_file.py`

That's actually one of the points.

    j lint

is shorter than

    python scripts.py lint

and the letter `j` is what the index finger of your right hand is pointing to on the keyboard. There is usually a tactile bump on that key. It is something you can type very quickly. You can also install shell completion to improve the experience further.

Ergonomics matters.

[culebron21]

Well, you can do the same trick with argh & a symlink in /usr/bin.

I'll agree this is some improvement in ergonomics if the executable supports tab completion.

With makefile + argh I can do this: put the script as a dependency of data file, and rebuild it if code changes.

    P=python3
    my_data_file.csv: my_script.py input_data.csv
        $P --flag1 --flag2 $^ $@

With your package, this becomes harder -- the file name and command name now are separated and must be checked for being in sync.

So, the package adds some features, but does it at some cost of other ways of interaction.

[yeti-sh]

Regarding sync checks which Make has as a built-in feature, I am not yet positive how to best implement it. Maybe something like

    @pre(file_name=_file_is_in_sync)
    def build(file_name: Path):
        ...

I believe such libraries do exist even, but I haven't yet researched the topic; if jeeves proves to be useful for the simplest use case then it will make sense to expand its scope.

[yeti-sh]

> argh & a symlink in /usr/bin.

- Is putting a symlink to one of your project directories, probably residing in $HOME, to /usr/bin/ a good practice?

- As an alternative one can put a symlink into ~/bin; but what if you have multiple different projects?

- And they can have different jeeves commands and different plugins installed. For instance, `j lint` implementations in different projects are work on are completely different.

Because these are different projects.

Rather, I prefer to have jeeves automatically create the executable command in each virtual env, and its behavior in different virtual envs will be different.

[culebron21]

I mean `sudo symlink /usr/bin/python3 /usr/bin/p` can make a good shortcut for python. The script name can be tab-completed.

[yeti-sh]

I see. The P key isn't that ergonomically placed though; and again, one will have to do this time and again for each virtual environment, right?

Why not use native Python methods, namely endpoints, instead, and automate this away?

[culebron21]

On Dvorak keyboard it is in a very convenient place. Anyway, one can assign any letter. Not everyone uses virtualenv -- this is very frequent in Django, but I didn't see it elsewhere since I stopped working with it in 2016. Data science that I saw, revolves around Jupyter and Docker.

Anyway, my point is that your package offers conveniences like those in existing packages, and not free but at a similar cost. (Actually, I also contemplated making my own plugins system for `argh`, but just wrote a single package with my own decorator to handle just the few types I needed: pd.DataFrame and gpd.GeoDataFrame. https://github.com/culebron/erde/ )

[yeti-sh]

I feel the majority still uses qwerty keyboards; I assumed that when choosing the name and the shortcut for the tool.

Experiences differ, and de gustibus on est disputandum; in my bubble, virtualenv is a must-have for Python development.

I have multiple Python projects, they run different versions of Python itself and its libraries, and for many of them Docker would be an overkill; so it is hard for me to imagine my routine without virtual environments.

I employ pyenv to manage them but venv is a venv.