> [conflicts in virtual environments are] most likely our problems, but we aren't the users that python is made for. We're support for those users.

Maybe? I mean, if people aren't noticing these issues and you are, how are they relying on your support?

> It's winning because its audience is not code specialists, but other kinds of specialists which sometimes need to use code. Their work often has a sort of immediate importance that ours often doesn't. It's not evaluated based on whether the techies like it, it's evaluated based on whether the scientists, the analysist, the students, and the {non-computery-engineering} Engineers like it.

There is no bright line. I'm a code specialist. I use Python as a tool to help build other code. I don't have any venv problems because my git repo has everything I need in it.

I mean that several professors have learned that I'm useful for resolving packaging related problems and they contact me for help with them. They expect that if they had a job in industry then there would be somebody who they would file a ticket with and then that person would help sort out the tangle.

Also, in a previous job, I was responding to tickets of that kind (e.g. "why does installing this version of foo prevent the bar from running at a all?").

Others provide support in other ways. The guy racking and stacking GPUs at a data center somewhere is doing so, at least partially, in support of some specialist wielding python to move data around.

Sure plenty of specialists do their own stunts, but plenty others do not and instead have support, institutional or otherwise, for that kind of thing.

That makes some sense, except you're mostly describing a division of labor where the people relying on you to fix their environments probably could do it themselves if you weren't around.

I think we agree these are not typical end users.

> Others provide support in other ways. The guy racking and stacking GPUs at a data center somewhere is doing so, at least partially, in support of some specialist wielding python to move data around.

I mean, the farmers help to feed me, too. Where do you draw the line?

My point is that they are typical. I think there are legions of them. Whole classrooms at a time, whole departments at a time, people whose job is to write python according to whatever procedures came down from on high.

We don't notice them because they're not participating in conversations about which programming language might be suitable. Instead they're having conversations about whether Python is necessary or whether they can get away with a spreadsheet.

> Python gets a lot of grief from the perspective of people who are frustrated because they didn't start off using virtual environments and now their global python package namespace is a nightmare.

I never got to the "nightmare" stage before learning about venvs.

But it's still nice sometimes to have an environment ready to go full of popular, non-conflicting things to play around with a REPL in.

I wonder why activating a venv ended up being implemented as a script you source (updates env vars in the current process) and deactivate (puts them back) rather than being something that puts you in a subshell (detects your current shell and re-invokes it with new vars).

subshells would let you nest venvs so you could have a "sane defaults" venv, and then you could descent into madness with another "wacky experiment" venv, and to return to sanity you'd just exit the subshell. As it is, deactivating takes you all the way out to the system package namespace (or maybe you can nest them, not sure, but it's up to the venv implementation and not your OS to restore the intermediate env).

> I wonder why activating a venv ended up being implemented as a script you source (updates env vars in the current process) and deactivate (puts them back) rather than being something that puts you in a subshell (detects your current shell and re-invokes it with new vars).

The venv is just the folders and Python stubs.

The activation script concept is probably just what happened to occur to Ian Bicking first. But also maybe the subshell UX isn't so pleasant on Windows?

Certainly others have implemented subshell-based venv management.

> As it is, deactivating takes you all the way out to the system package namespace (or maybe you can nest them, not sure, but it's up to the venv implementation and not your OS to restore the intermediate env).

The effects do not nest, at least not with the *sh activate script. You'd need to implement a stack of old environment variable settings.

But I think the use case you describe just doesn't resonate with a lot of people.

> But I think the use case you describe just doesn't resonate with a lot of people.

Yeah I suppose "flat is better than nested" is right there in the zen.

I guess I'm just an oddball. The idea of exiting all the way up to the root and finding nothing installed there except for the ability to descend into one or more specialized transient environments feels so... clean to me.

The other thing is, if you don't at least set $PS1 it gets hard to remember which level you're at.

You can configure direnv to en/disable envs based on dir enty/exit, so as long as your shell prompt shows your cwd you also know which env you're in. Less overall to think about if you bind the two states together.