Decentralised / Relative mode

[Francisco Lourenço]

From virtualenvwrapper docs as one of it's features:

1. Organizes all of your virtual environments in one place.

I've seen some pythonistas, who use barebones virtualenv, preach the benefits of storing each virtualenv in the corresponding project's root. It makes a lot of sense to me:

1. You don't have to name your env when you use vex, don't need to remember, and it's faster to use.
2. You don't end up with orphan envs in ~/.virtualenvs after deleting the project they belong to.
3. All files related with a project, are contained inside that project's directory.

Once decentralised mode is activated in ~/.vexrc, you wouldn't need to specify which env you want to use anymore. Vex looks in the directory you are working on, kinda like git does. Examples:

• vex --make creates a ./virtualenv in the current directory.
• vex --remove removes the ./virtualenv in the current directory.
• vex (iPython) spawns a shell (or iPython) using the ./virtualenv in the current directory. If one is not found, vex searches the parent directory recursively until it finds one.
• vex --env <nameOfEnv> would allow you to quickly tap the traditional centralised directory, by specifying the name of the env using the --env flag.

Does something like this make any sense to you?

[Sasha Hart]

--path is already implemented which will let you use virtualenvs placed anywhere you want.

You can also directly invoke ./env/bin/python.

There is no way I am going to change the default way that vex functions so that the current way requires a flag. That isn't fair to current/past users.

Thanks for your ideas.

[Sasha Hart]

I also didn't mention that vex's scheme for interpreting positional arguments would have to be completely reworked for this. So I'm afraid it's very difficult.

I think this functionality is an excellent candidate for a small shell function, other utility or something because the amount of error checking required isn't great. If you want to make something I'd be happy to help (even if it doesn't involve vex)

[Francisco Lourenço]

By the way, it has never been proposed that the default mode was changed, but an option to change the default action.

[Francisco Lourenço]

Hi, I noticed you made --path work with --make, this is great.
Would it be possible to set --path in ~/.vexrc?
Then one could use something like path=.virtualenv and use it automatically decentralised.

[Sasha Hart]

I still think proposals on these lines will break the way vex currently works, changing the interface in an unexpected way. vex takes a first argument naming the virtualenv. That is the normal mode of operation. I supplied --path for convenience in a certain case, but not because I want it to be the default (because there is already env/bin/python whatever.py and source env/bin/activate). That complicates the argument parsing enough as it is. I do not want to make another special case for when --path has been set in .vexrc. Also, that idea won't work without other changes: for good reason (potential ambiguity of writing 'vex foo' with a local dir named foo, causing confusion and disasters) --path uses absolute paths, so if you could set it in .vexrc, you would always be using the same virtualenv, which is pointless.

I think what you want here is really a tool like autoenv (which already exists separately of vex) or if that doesn't suit, something new like a quick cd alias, which again can coexist peacefully with vex. Or just use that instead of vex, I don't mind. But I like tools to work orthogonally where possible.

With respect to you and your ideas, I just don't personally see in this proposal a strong quality benefit to vex which offsets the additional interface complexity, implementation, etc.
I don't use autoenv type functionality and honestly I don't know anyone who does - if you do, more power to you. But I meant vex to be simple. I made the tool I needed, then shared it. So it should not be surprising that it becomes harder and harder to get features into vex unless I can offset them or they fit in extremely well.

And I have some of my own reasons I wouldn't like to implement autoenv-type functionality inside vex. I don't want to increase dependence on .vexrc without strong reason, because that ratchet only turns forward. Also, the magic confusing nature of this makes me uneasy enough as it is, but then I think about the eventual inevitability that someone will say "let's put a .env in this repo so that anyone who issues cd into the checkout directory and uses vex will run malicious code." That makes me nervous.

it's impossible to have a project which will please everybody, so someone's preference will always be left behind. In this case I'm afraid your preference runs against what I think is good for vex in its niche, and what I personally prefer.

[Francisco Lourenço]

Also, that idea won't work without other changes: for good reason (potential ambiguity of writing 'vex foo' with a local dir named foo, causing confusion and disasters) --path uses absolute paths, so if you could set it in .vexrc, you would always be using the same virtualenv, which is pointless.

Actually --path seems to accept paths relative to the current working directory, like one would expect it to, so yes, it works. And it doesn't matter that there is a directory named foo, since when --path is used, a env is specified by definition, therefore the next argument is parsed as a command, so foo is not interpreted as the name of an env, and I could't make trouble so far.
These are the results of the tests I did with 0.0.18 at least.

I think what you want here is really a tool like autoenv (which already exists separately of vex) or if that doesn't suit, something new like a quick cd alias, which again can coexist peacefully with vex. Or just use that instead of vex, I don't mind. But I like tools to work orthogonally where possible.

autoenv doesn't seem what I'm looking for. What I appreciate in vex is its simplicity and that it is shell independent. It doesn't try to modify the current shell env, but instead it spawns a sub-shell (or runs a command), which is much more sane and simple than the alternatives. I just wish this simplicity was transversal to other aspects. If you "meant vex to be simple", than you would do without centralisation. Sure you can say that is a matter of taste, but it is not more simple.

Nonetheless, I'm not neglecting the added complexity of implementing these features and understand your motives.