I congratulate you on the popularity and integration of python into Operating Systems, however this has led setting up a python environment requiring several more steps. Before, these steps were not required and installing packages did not lead to external management conflicts. It was way easier to go from idea to code.
With common adoption and the added security of environments, comes a cost of usability.
We can chalk this up as just one more thing the user needs to learn, or we can recognize it as a rock in the road between idea, usability and execution.
I post this without prior knowledge of the discussion on this topic and beg forgiveness for stepping on any political toes or entrenched sentiments. I submit this only as a user from a previous version , and using the language more, recently.
I simply propose an alias command like i have set up in my local environment that creates a venv in the project file: “pystart”
pipx is not the solution as it does not make it’s installed dependencies available globally, as i’ve run into missing dependency errors running a script .
i am very likely going about this all wrong, and welcome configurations i am ignorant about that eliminate this alias altogether for my workflow, but my best searches so far have just revealed an attitude of “change your behavior to fit the language” and “entering two to three extra commands before you get started is really not that big of a deal” which seems odd because pythons are flexible.
adding this alias to main would modify the user behavior towards safety, being conscious of security environments and package management, while simultaneously increasing usability for all.
-Humbly submitted by a Python appreciator and Python3 enjoyer
I think something like pyvenv pystart instead of python -m venv pystart would make more sense, but this already existed at some point, and was removed because of potential confusion about which Python interpreter it’s tied to: Drop the pyvenv script · Issue #69341 · python/cpython · GitHub
But isn’t that the same problem with pip and python -m pip? Is there an assumption pip is used more often than python -m venv, even though it’s the recommended approach? Or is this fine because of python -m ensurepip?
pystart would not and does not have this confusion in my set up. using the “env” contributes to this, whereas pystart is it’s own thing and is in line with the secure behavior everyone wants.
this is great, and i will check this out, but learning a new tool does not improve pythons useability. It’s the equivalent to “conform to the language” .
To me it’s like saying: Before you could start a by turning the key, now you just need to push a button, but that button requires an app to be able to push it, for security and collision reasons.
Ideas like this have been discussed multiple times in Packaging (looking for the keyword platypus might put you on the right track to finding some of the relevant discussion threads).
Honestly I am not sure what your idea is. It is a bit vague. Or maybe I am just not understanding what you mean. It would be helpful if you would describe a complete use case from top to bottom in simple straightforward sentences.
If what you want is uv’s script dependencies (which is based on “inline script metadata” which is implemented in other tools besides uv), then there you have it.
You say you don’t want to learn a new tool, but you propose a new thing called pystart that one would probably need to learn anyway, no? So I am a bit confused. : D
Why don’t you post the content of you pystart alias here?
Let’s suppose you are on a new OS install and setting up python. You install python 3 through the pkg manager and now want to run a script. So far the commands you’ve entered are Sudo apt install python3 . What are the next commands you must enter before app.py runs ?
Why did you run sudo apt install python3? If the “best way” to install Python was sudo apt install uv, would that satisfy you? You could then run app.py using uv run app.py[1].
Or is your complaint that you want this functionality built into the distributions shipped by python.org? While I can understand that desire, you’re already not using a python.org distribution if you use the build provided by your OS. There are people working on the question of what python.org should provide in the way of “official” distributions of Python, but it’s a complex and difficult problem.
So, to address your original post:
We’re working on this question, but it’s not as simple as you seem to think.
In the meantime, uv almost certainly gives you the sort of experience you want. It’s up to you whether you view it as an acceptable solution or not.
I’m not sure how helpful what I’ll say is, but you could write a simple script to do this. A few weeks back I wrote this in bash and it’s been incredibly helpful so far
function virtualenv() {
local env_folder="$1"
local createdNow=false
# If no argument is provided, check for existing environments
if [ -z "$env_folder" ]; then
if [ -d ".venv" ]; then
env_folder=".venv"
elif [ -d "venv" ]; then
env_folder="venv"
else
echo "Usage: ${FUNCNAME[0]} <env_name>"
return 1
fi
fi
# Create the virtual environment if it doesn't exist
if [ ! -d "$env_folder" ]; then
python -m venv "$env_folder"
createdNow=true
fi
# Activate the virtual environment
source "$env_folder/bin/activate"
# Automatically install requirements if the environment was just created
if $createdNow && [ -f "requirements.txt" ]; then
echo "Automatically installing requirements.txt, please wait..."
pip install -r requirements.txt --require-virtualenv
fi
}
I’m sure more functionalities could be implemented and this could also be written in PowerShell, but this is just a little something that can be done instead of having a command built in to python
“if the best way to use python is this other niche tool that is not python, why did you not use that ?”
i mean… i only found out about it from replies to this post and it was not a prominent reply to the regular first level responses to my issue on reddit, stack, ect. pipx is, but is another tool like uv.
Awesome. I hope a user friendly solution is found. My request is more along the lines of something as simple as a “SHOULD” guidance or policy in the Docs for operating systems to set up a pystart trigger at install.
This is great, and i thank you. The problem is, i move systems a lot, upgrade to incompatible kernels and lose track of dotfiles.
It’s more reasonable to expect a language to just run, rather than having to hack my way around the language implementation.
As an example is: if/when I install racket, clojure, gcc, js, it just runs in their respective environments without collisions with the operating system necessitating further tools.
It’s wild to think about why and how everyone just sort of allows python to have this giant integration danger zone and breaking behavior, in a way c has never done.
The more i think about it and the more i see helpful but ultimately cope replies like “use this other tool to work around an obvious flaw” or “use this code” the more i’m curious why this is the case and what decisions led to the state of affairs that a warning about an “externally managed environment” is a satisfactory hurdle a user must contend with.
I’m trying to think of another language i’ve worked with that behaves this way. Java ? .net maybe. yeah .net and it’s eye of sauron takeover of the operating system in the early 2000’s
Again, i say this as someone who admires python’s growth and ubiquity.
I’m not crazy though right ? I shouldn’t have to run other tools or add twenty odd lines of bash to run a script file for an already installed language ?
When you install C, you don’t install C, you install gcc. When you install Javascript, you (probably) install Node. Installing a tool that isn’t technically “the language” is not as uncommon as you seem to be suggesting.
I’m not saying Python doesn’t have problems, just that you may simply be more used to the problems of other languages.
After all, you can just install Python and run a Python script. If it has dependencies, you need to do some extra work, certainly, but (for example) C is far worse in this regard, having no package manager, and no package repository.
It’s worth remembering that Python is over 30 years old now. Its ecosystem is much better than languages of a similar age. Newer languages have in turn improved things significantly, but they don’t have years of history to consider when making any change. Python will get there, but it’s slow simply because Python is popular and hence has a huge user base invested in the current ecosystem.