Rye: A Hassle-Free Python Experience
Rye is a Python project and package management tool for developers. It simplifies Python installations, project management, dependencies, and virtual environments. Installation instructions are available for Linux, macOS, and Windows systems. Users need Rust and Cargo for Rye.
Read original article
Rye is a project and package management tool for Python, aiming to provide a hassle-free experience for developers of all levels. It offers a unified solution for installing and managing Python installations, projects, dependencies, and virtual environments seamlessly. Designed to support complex projects and facilitate global tool installations, Rye caters to various needs like monorepos. Installation instructions are available for Linux, macOS, and Windows systems, including downloading the binary or using a curl command. It's recommended to have "Developer Mode" activated on Windows before installation. Rye does not use signed binaries yet, so users may need to allow execution manually. Rust and Cargo need to be installed to use Rye, which can be done via cargo install. For further customization and detailed installation guidance, users can refer to the provided resources.
Related
Binrw
The tool binrw simplifies binary parsing and serialization with a declarative approach, offering readability and maintainability. It supports common tasks, generics, custom parsers, predefined types, and is safe for various environments.
First Class Contexts – Rye Language
Rye Language introduces first-class contexts for scoping Rye words, creating parent-child relationships. Context paths access values, restricting direct changes for control. Evaluation and isolation mechanisms enhance structured code organization.
Show HN: R2R V2 – A open source RAG engine with prod features
The R2R GitHub repository offers an open-source RAG answer engine for scalable systems, featuring multimodal support, hybrid search, and a RESTful API. It includes installation guides, a dashboard, and community support. Developers benefit from configurable functionalities and resources for integration. Full documentation is available on the repository for exploration and contribution.
Python Modern Practices
Python development best practices involve using tools like mise or pyenv for multiple versions, latest Python version, pipx for app running. Project tips include src layout, pyproject.toml, virtual environments, Black, flake8, pytest, wheel, type hinting, f-strings, datetime, enum, Named Tuples, data classes, breakpoint(), logging, TOML config for efficiency and maintainability.
Python Has Too Many Package Managers
Python's package management ecosystem faces fragmentation issues. PEP 621 introduced pyproject.toml for project configurations, leading to new package managers like Poetry. Conda offers robust dependency management, especially for data science workflows.
71 commentsE.g., we recently added support for "universal" resolution in uv, so you can generate a locked requirements.txt file with a single resolution that works on all platforms and operating systems (as opposed to _just_ the system you're running on). And Rye supports it too in the latest release.
[1] https://github.com/astral-sh/uv
---
I work on Rye and uv, if you have any questions :)
From their philosophy page: https://rye.astral.sh/philosophy/
> No Python Binary Distributions: CPython builds from python.org are completely inadequate. On some platforms you only get an .msi installer, on some you literally only get tarballs. The various Python distributions that became popular over the years are diverging greatly and cause all kinds of nonsense downstream. This is why this Project uses the indygreg standalone builds. I hope that with time someone will start distributing well maintained and reliable Python builds to replace the mess we are dealing with today.
And here is info about those particular indygreg builds.
https://gregoryszorc.com/docs/python-build-standalone/main/
It is, however, possible to choose a different Python.
https://rye.astral.sh/guide/toolchains/
I've never really experienced the problem they are describing. Any official Python build I've gotten from python.org has worked. Every normal old Python I've gotten from my distribution's package manager has worked. Every Python included with an official Docker container image has worked.
I'm sure their special builds will also work just fine, but their non-standardness gives me pause. There's even a list of behavior quirks. Why are we adding quirks to something that has no problems? And the fact that the rye philosophy seems so intent on using them, turns me off from it compared to the alternatives that sensibly default to using the Python you already have available on your OS.
I love Rye. It does what it says on the tin. It makes the whole venv/Python-version/packaging process actually pleasant, and it’s invisible to someone used to Python-official usage (pyproject.toml et al). And it makes Python feel like Cargo, which is a great thing to work with too.
I love Rye. After using package managers from other languages like cargo and hex, the lack of a similar system for Python always had me yearning for more. I'm really happy to say Rye has completely solved this itch for me, and its a real pleasure to use as someone who doesn't want to install different tools to manage venvs, python versions and my project's dependencies. Rye just does it all.
> Rye is still a very experimental tool, but this guide is here to help you get started.
While I’m really excited about this project, I’m planning on waiting until this project is in a more mature stage. I am a big fan of everything else the Astral team has put out so I have high hopes for this.
Is there a reason why Python has taken this long to get a mature alternative to "requirements.txt"?
(I hit similar things with libressl/libcrypt from time-to-time. It is not quite exactly a drop-in replacement world for these things. It's painful enough to make back-porting modern SSL dependent code a royal pain, of destroyed shared lib dependencies)
Is there a security difference between running a shell script that runs a binary vs running a binary directly? Or downloading a executable from the browser vs downloading a shell script using curl?
I get that running the shell script can subjectively look more scary, but doesn't it just basically reveal the inherent danger of running an exe anyhow, assuming there's no code signing keys involved?
* Python has too many package managers *
Also, the CLI tooling doesn't even depend on using Hatchling as a build system, which is an understated benefit.
Unless one's got a particularly weird use case where they actually need to know the ins and outs of PEP 517 (Maturin/PyO3 with system specific dependencies, for example) it is going to be completely fine for the vast majority of packages with minimal additional configuration.
[0] https://mac.install.guide/python/install [1] https://mac.install.guide/python/use-rye
Update: looks like this might be supported, from the FAQ...
Can I use Rye Alongside Other Python Installations?
Rye given it's experimental nature does not want to disrupt already existing Python workflows. As such using it alongside other Python installations is intentionally supported. Even if the Rye shims come first on the PATH, Rye will automatically resolve to a different Python installation on the search path when invoked in a folder that contains a non Rye managed project.
As such the answer is a clear yes!
I would appreciate it if people doing videos presentation would switch to quieter keyboard, use directionnal microphones so that only their voice is recorded or edit the sound afterwards to quiet down the keyboard frequencies out of respect to their audience. It is not hard to do.
There's a few bits I don't like in uv, but I intend to submit patches soon.
The one thing I think sets these projects back is the naming. Rye, uv... They just aren't as good names as pip, pip-tools, venv etc. This could make it harder to convince people of their legitimacy. But I could be wrong, maybe they will succeed based on their merits.
A "Cargo for Python" I find a bit misleading. Python is very different to Rust and upon learning Rust I didn't find anything that I hadn't already got in all my Python work. If anything Cargo is just 'the best parts of all packaging software so far, including Python".
* Installation through Homebrew * Plugin for Oh My Zsh!
1: I develop and run Python projects in Docker containers.
2: Each Python project has a setup.py.
3: The setup.py installs dependencies from their git repos.
What benefit would I get from using any additional tools?
A quick search turned up this unanswered question: https://github.com/astral-sh/rye/issues/888
I am wondering why the developers chose not to propose to fetch the missing version when doing `rye sync`. I would expect anyone preparing the video tutorial to think "wait, this is stupid, let's fix this asap" instead of showing off potential users how unfriendly the ux is.
So far, I love Rye! So fast and no roadblocks yet.
This seems an impossible task on linux, where yum/apt packages are installed long before any higher-level python tools like poetry or rye. With the continual sprawl of "one tool to rule them all" in Py & Js, I'm thankful for Go being a much more consistent ecosystem.
I'm OK with the pythons that are provided my the OS I'm using (including Deadsnakes) so this side of rye doesn't appeal to me. I've started using uv to create virtualenvs, though, so that's probably the gateway drug. We'll see.
I see that UV is bragging about being 10-100x faster than pip. In my experience the time spent in dependency resolution is dwarfed by the time making web requests and downloading packages.
Also, this isn't something that runs every time you run a Python script. It's ran once during installation of a Python package.
will not go back to pipenv / poetry unless uv does something truly awful to me
I feel more meh about rye, except as a way to use uv for package management
and I don't understand why astral is a company
1. Can anyone recommend a good file layout/organization for a polyglot monorepo that contains Python, C++, and JS?
2. Does the build system need to be use something like Buck/Bazel?
3. How do you usually open your project in an IDE? do you open the root of the monorepo, or do you open each subproject separately?
on the other hand, I've found Go to be meaningfully superior for many things, and Rust to be meaningfully superior for many other things, and Scala excellent for the JVM and I simply can't actually recommend other languages for professional greenfield work outside of exceptionally niche cases.
We are open to the cutting edge, but it can't be too sharp or rough.
How does this compare do developing inside a container?
Why would it not work?
Out of curiosity though: is there anything like this that exists, but less Python-specific?
Great thanks to all the team.
(happy Nix user)
Probably not actually a large issue here since it uses pyproject.toml which is what Poetry uses and seems to be the standard people are moving to.
daily reminder: you can specify exact commits from git repos.
just prefix any other package manager with matrioskhka
e.g. python -m matrioskha rye install pip install pipx setup.py install
A single distribution command for all of your projects.
Why don’t we just stop creating those problems =p
I only install Conda on untrusted machines.
$ python3 thing.py
Don’t see the hassle there.
Related
Binrw
The tool binrw simplifies binary parsing and serialization with a declarative approach, offering readability and maintainability. It supports common tasks, generics, custom parsers, predefined types, and is safe for various environments.
First Class Contexts – Rye Language
Rye Language introduces first-class contexts for scoping Rye words, creating parent-child relationships. Context paths access values, restricting direct changes for control. Evaluation and isolation mechanisms enhance structured code organization.
Show HN: R2R V2 – A open source RAG engine with prod features
The R2R GitHub repository offers an open-source RAG answer engine for scalable systems, featuring multimodal support, hybrid search, and a RESTful API. It includes installation guides, a dashboard, and community support. Developers benefit from configurable functionalities and resources for integration. Full documentation is available on the repository for exploration and contribution.
Python Modern Practices
Python development best practices involve using tools like mise or pyenv for multiple versions, latest Python version, pipx for app running. Project tips include src layout, pyproject.toml, virtual environments, Black, flake8, pytest, wheel, type hinting, f-strings, datetime, enum, Named Tuples, data classes, breakpoint(), logging, TOML config for efficiency and maintainability.
Python Has Too Many Package Managers
Python's package management ecosystem faces fragmentation issues. PEP 621 introduced pyproject.toml for project configurations, leading to new package managers like Poetry. Conda offers robust dependency management, especially for data science workflows.