make it executable as a module:

[techtonik]

python -m vex

[techtonik]

It also makes The Path Problem optional.

[sashahart]

Supporting -m is trivial to do (no PR necessary), so at first inspection it seems almost free. I've considered it a few times before, including before the initial release. But I've refused it before and at least for today, I'm going to refuse it again. If I eventually do it, I will not recommend or document it.

So the discussion is really why you as an experienced user specifically need this as a one-off, because it's never going to be public interface for vex. And whether including that one-off in vex as publicly released outweighs the possibility that I will have to forcibly deprecate it down the line.

I think you've suggested here that the PATH problem is somehow a problem specific to vex, but anyway it isn't (perhaps the README should rephrase). And supporting -m doesn't make the problem optional either. The same users who don't ever set up PATH are still going to have this issue for every command line utility other than vex.

Moreover, python -m vex is a lot of extra prefix to type every single time you want to run something in a virtualenv, which is probably many times per day. If I saw a utility telling me that this is how I was going to interact with virtualenv, I would immediately throw it away in disgust. It's baroque. And even if I just got in a bad habit of invoking the utility with python -m, believing that this was the right way, I would eventually get very irritated with how much daily friction that was, form a very bad impression of the tool and junk the tool, even though it was my bad habits which made this happen. And beyond that, I really don't like making incentives for users to skip 10-second configurations that just make life better on the command line for a long time afterwards, if they don't have a basic understanding of the issues involved.

So in my mind it really isn't as simple as "just put this in now, it's free". Without a use case I can agree with, I see python -m as an attractive nuisance, and therefore not completely free.

As far as the README, vex operating on the command line and in interaction with confusing things like bash means that a lot of people are going to be confused and file issues based on confusion unless the README teaches basic facts of life, so that might as well include PATH as well since dealing with PATH is about as avoidable as gravity. I'm not going to bullshit people that there is any way for vex or anything like it on currently existent platforms to avoid issues like what the user does about PATH.

[sashahart]

Closing, but feel free to complain or discuss further

[techtonik]

I've refused it before and at least for today, I'm going to refuse it again

Not an argument for me.

supporting -m doesn't make the problem optional either.

Tools that need present in PATH have installers, such as Mercurial. Tools that are installed using pip support -m interface, such as virtualenv. It is up to users how do they want to install things. If I want to try vex - I'll do pip install vex + python -m vex. If it will be useful - I'll add it to user menu with shortcut keys (I am using Far Manager).

in interaction with confusing things like bash

Yes. I noticed that it didn't change command prompt for cmd.exe

Closing, but feel free to complain or discuss further

I can live with forked version FWIW. =)

[techtonik]

This is actually a proper fix for #12.

[sashahart]

Encouraging users to type 'python -m vex' in front of every command is not proper, it's horribly clumsy. That's exacerbated by vex already being a prefix to commands, and being something you are going to type many times per day rather than a one-time bootstrap. The high likelihood that some poor Windows user who never knew better will be told by some "expert" to always type python -m before every command makes me feel so bad for that person.

Against that, I am weighing your own personal whim, that you decided you don't want to set up PATH once for all your command line utilities other than hg. This must make it hard for you to try out and adopt new command-line utilities from places like PyPI, because I am certain that almost none of those ship with big fat installers.

If we are going to use the word proper here, the proper thing to do is configure your command prompt when you decide to do a significant amount of command line interaction in Windows, because otherwise you are fighting uphill every day. Life is already hard enough in non-VS Windows development without artificially handicapping yourself by refusing to configure anything. But, even *nix users are editing a few rc files when they get started to make life easier.

'python -m' prefixing is a magical incantation, otherwise meaningless, which has to be repeated many times per day. This kind of repetitive work is exactly what a computer should be doing. What if somebody wrote software that took care of that?

In fact, they did write it already. And the way you configure it is to set PATH. No crappy prefix workaround necessary. The perfect option for anything you might be typing a hundred times per day. And while Windows makes it unusually awkward, it only takes a few seconds anyway. After that, literally every command line utility you get from PyPI (at minimum) can work the same way. It's just part of getting set up properly.

virtualenv has had its share of questionable decisions that had to be walked back, so it was never much of an argument to say that virtualenv supports -m, so you should too. All it means is that -m seemed cheap and someone asked for it, so it was thrown in. and now it became part of people's arsenal of shitty workarounds that they use to kick the can down the road instead of getting set up. and then they wonder to themselves every day why everything takes so long and is so frustrating to do. It's because they have adopted kicking the can down the road as a general policy.

[techtonik]

On Windows, the shitty workaround is cmd.exe. The correct system configuration is to use ConEmu + Far Manager. python -m vex is needed to use vex that is specific to used interpretator (and not the one that is available from PATH, because every installed Python managed to add its Scripts/ dir to PATH with multiple vex in it. I invoke vex with two keypresses - F2 and v. Everything else is substituted automatically. Except for shitty problem of locating vex in "proper" PATH.

If your vex is updated, what would you use to update it? python -m pip install vex or pip install vex? Are you sure you're not invoking pip from without your environment? Maybe add an option vex update then?

Mercurial chose to ship installer for good reasons.

[sashahart]

ConEmu + Far Manager

wat