Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rye wrongly assumes a project is managed by Rye if there is a pyproject.toml #1285

Open
laclouis5 opened this issue Jul 27, 2024 · 3 comments

Comments

@laclouis5
Copy link

Steps to Reproduce

Create an empty project with a pyproject.toml file:

mkdir test
cd test
touch pyproject.toml

Then rye show outputs:

project: <unnamed>
path: /home/louis/Downloads/test
venv: /home/louis/Downloads/test/.venv
target python: [email protected]
venv python: [email protected]
virtual: false
configured sources:
  default (index: https://pypi.org/simple/)

This indicated that Rye thinks that the project is managed by Rye, but it is not the case (it could be manage by anything else such as Poetry).

Additionally, Rye does not seem to honor the managed flag in the pyproject.toml configuration:

[tool.rye]
managed = false

Adding these lines results in the same output from rye show.

Expected Result

Rye shouldn't assumes a project is managed by itself solely based on the presence of a pyproject.toml file since other Python project managing tools such a Poetry may use it for this same purpose.

This results in the impossibility to manage a Python project with Poetry using a Rye "system" Python toolchain (global-python = true).

Actual Result

Poetry fails to find Python toolchains fetched by Rye.

Version Info

rye 0.37.0

Stacktrace

No response

@bluss
Copy link
Contributor

bluss commented Jul 29, 2024

What is the more specific harm here? It would make it easier to understand what to change if it was more specific about what's wrong. IMO it's only good that rye can interact to some extent with projects it doesn't manage - for example rye run works on unmanaged projects today. And rye show should not modify the project it is inspecting (that would be a bug).

@Thyrst
Copy link

Thyrst commented Oct 18, 2024

What is the more specific harm here? It would make it easier to understand what to change if it was more specific about what's wrong. IMO it's only good that rye can interact to some extent with projects it doesn't manage - for example rye run works on unmanaged projects today. And rye show should not modify the project it is inspecting (that would be a bug).

Harm is this: This results in the impossibility to manage a Python project with Poetry using a Rye "system" Python toolchain.

I encountered this problem too. I want to use the global Python package managed by Rye to work with projects that are not managed by Rye. If a project is managed by Poetry, Rye incorrectly assumes it is Rye project and won't let me call python -m poetry.

@Thyrst
Copy link

Thyrst commented Oct 18, 2024

Inspired by #998 (comment) I did this as a workaround:

In ~/.zshrc or ~/.bashrc:

export RYE_PYG="$HOME/.rye/py/[email protected]/bin" # replace with your Rye global environment path

pyga() {
    # Save current PATH in a backup variable
    export OLD_PATH="$PATH"
    
    # Add Rye-managed Python to the beginning of PATH
    export PATH="$RYE_PYG:$PATH"

    echo "Global Python activated. Run 'pygd' to restore the previous PATH."
}

# Function to deactivate and restore original PATH
pygd() {
    if [ -n "$OLD_PATH" ]; then
        export PATH="$OLD_PATH"
        unset OLD_PATH
        echo "Restored the original PATH."
    else
        echo "No previous PATH to restore."
    fi
}

Running pyga will then override the PATH to use the global Python environment managed by Rye.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants