Does any sane person use python managed by Rye 😂

[MatthewScholefield]

When installing rye for the first time it prompts for the desired behavior when running python or python3 outside of a Rye managed project:

At first, choosing the default options (Rye managed shim) seems like a no-brainer. But then I realized this catapults you into this weird state where you actually cannot use any global libraries you installed using pip. This means that if I have some simple script that needs a common dependency like requests or click, I can't just do pip install requests click and then python3 simple_script.py; misleadingly, pip install succeeds but then python3 simple_script.py still fails with ImportError.

Similarly, if you do pip install ipython, and then follow up with ipython3, this will spawn Python using the system interpreter rather than the environment used by python3. And running rye install ipython or python3 -m pip install ipython will insert a third level of confusion.

So my question, given all of this, is basically:

1. Do people understand the nuance here when they select their environment and legitimately prefer the first option?
2. (Depending on the result of question 1) What's the ideal path forward?
   a. Insert a new Rye shim for pip so that everything in the global environment refers to the same thing (and maybe remove the rye install -> rye script install alias to reduce confusion)
   b. Remove the rye-managed shim from the default option on the installer
   c. Something else (comment)

I know I've been vocal about this already before (#1093), but I'm bringing it up again here because this confusion is one of the core reasons why I'm hesitant to recommend rye to my fellow developer friends. As a whole, I think rye is a wonderful tool in the Python ecosystem and deserves to be the de facto standard. However, as it stands right now, I feel that this default rye-managed environment option will significantly confuse new Python developers making them hate Python package management even more (relevant article).

[sswatson]

Personally I very much prefer Rye's design choices in this regard.

If I want to add requests and click, I just do rye add requests click. It's fewer keystrokes than pip install, and it solves the reproducibility problems that come with using Pip.

You have a good point about the risk of accidentally doing pip install, but I don't have a problem with that because I don't have pip on my path. The only global python for me is Rye's shim, so if I try to do python outside a project, I get an error. I do have a special "project" with common packages installed so that I can do quick one-off things without having to create a project folder for them, but I have it set up so that I have to explicitly activate that project's virtual environment before being able to access it. Also, now that I'm using uv, setting up a new project is so quick and easy that I mostly just do that.

The way I see it is that some of the problems with Python that Rye aims to solve emerge from common usage patterns. Solving them requires both proper tooling (e.g., Rye) and changes in habits. Therefore, there is significant tension between accommodating what Python users are accustomed to and tackling the challenges the tool is meant to address.

[MatthewScholefield]

Just a quick followup here, so it sounds like you don't specifically use a rye managed system Python since everything you do is within a local rye environment (is that correct?). If this is the case, I'm still curious if you use the system managed python3 executable outside of a local rye project and if so, what use you have for it.

Personally, I'm kind of thinking it would be nice if when you choose that option, it would replace pip with some executable that just prints a message like Please create a python environment via rye init and then add packages via rye add.

[sswatson]

I'm on macOS, and it doesn't come with Python anymore. So I actually don't have a Python apart from the Rye-managed one.

There are times when it feels a bit heavyweight to create a virtual environment, though, so what I do in those situations is have a single Python virtual environment lying around that I have configured with my standard tools. Then I can do pyga (python global activate) which is aliased to the necessary command to activate that virtual environment. This environment is housed in a particular directory (of course), but I use it wherever I'm working.

Generally I'm quite happy with this arrangement: I mostly use local virtual environments (as is generally advised with any Python setup), I can use a "global" Python environment if I want, for convenience, but it's hidden behind an activation command so if I invoke a command like python or pip outside of a context where it makes sense, I get a helpful error message.

[chrisjsewell]

@MatthewScholefield I would uno-reverse that on you and ask: "does any sane person install things into a global python environment" 😉
this is basically advised against in every Python guide, e.g. https://packaging.python.org/en/latest/guides/installing-stand-alone-command-line-tools/

[MatthewScholefield]

Thanks, I mean that makes sense, for standalone CLI apps. I guess my question is more about the purpose of having a rye managed system Python. Since if you do install every Python CLI app in a standalone environment then having a rye managed system Python version shouldn't really make a difference.

Curious, what do you use the rye-managed Python for? Personally, I find it quite useless since the default Python REPL is quite underpowered compared to ipython.

[my1e5]

This means that if I have some simple script that needs a common dependency like requests or click, I can't just do pip install requests click and then python3 simple_script.py

uv (which eventually will superseed Rye) has just released some new features related to this problem - see https://docs.astral.sh/uv/guides/scripts/#running-a-script-with-dependencies.

It allows you to do

uv run --with requests example.py

Also, Python recently added a standard format for inline script metadata. This allows the dependencies for a script to be declared in the script itself.

# /// script
# dependencies = [
#   "requests<3",
#   "rich",
# ]
# ///

import requests
from rich.pretty import pprint

resp = requests.get("https://peps.python.org/api/peps.json")
data = resp.json()
pprint([(k, v["title"]) for k, v in data.items()][:10])

And uv run supports this.