rye
python-build-standalone
Our great sponsors
rye | python-build-standalone | |
---|---|---|
31 | 11 | |
11,368 | 1,544 | |
10.9% | - | |
9.7 | 9.1 | |
1 day ago | 6 days ago | |
Rust | Python | |
MIT License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rye
-
Trying Out Rye
I tried out rye + uv on a recent greenfield project. They are awesome tools and I'm really excited about their potential.
For me, rye (+ uv underneath) has perhaps the perfect workflow for an open source Python project. So I'm definitely using rye for that from now in -- instead of, say, poetry -- or hatchling directly, following the PyPA boilerplate[1].
You have a way of doing local development against any Python interpreter version. You have a way of tweaking dependencies. It all works atop "standard" PyPA infrastructure like pyproject.toml. You have a single command to build[1] project artifacts, like wheels. And you have a single command to publish new artifact versions to PyPI[2].
I think if you're doing local development on a project that is not meant to be published to PyPI, like a private Django project, then whether to use rye becomes more of a debate. For example, for a Django project I'm working on, I decided to just use uv directly, along with a Makefile. This is because during development of a Django project, I preferred to just use a plain requirements.txt (really, requirements.in) file, avoid the sync/lock workflow that rye imposes, and avoid the need to use something like rye run. And rye's ability to package didn't solve a problem since the Django project wasn't being deployed via a PyPA packaging mechanism.
But this is probably also because the Python interpreter/venv management problem, for me, is already handled by pyenv. I think if you're not already a pyenv user, rye is even more appealing because it handles "all" of the Python issues -- interpreters, requirements/dependencies, and packaging/publishing. (As well as a number of other standard issues besides, like testing, linting, and formatting.) But, in my case, I could hand venv management to uv, and then make dependency management part of a larger Makefile for my Django project, including custom linting, testing, and deployment steps. I wrote a little bit about my high level thoughts on Python packaging and dependency management, though this post was written before rye and uv were out.[4]
I'll also say, I found a little bug in how rye (+ hatch) interacted with my local git setup, and reported it to the rye team, and they helped me get to the bottom of it rather quickly.[5]
[1]: https://packaging.python.org/en/latest/tutorials/packaging-p...
[2]: https://rye-up.com/guide/commands/build/
[3]: https://rye-up.com/guide/commands/publish/
[4]: https://amontalenti.com/2022/10/09/python-packaging-and-zig
[5]: https://github.com/astral-sh/rye/issues/793
-
Pyenv – lets you easily switch between multiple versions of Python
I've been using Rye[0] lately, which has been pretty good. It's really just a wrapper around a bunch of underlying tools - it's nice to not have to worry about those and let Rye do it's thing.
All that being said, the creator of Rye is 100% cognizant of that XKCD comic, this [1] is a nice read.
I'm not super well versed in Python tooling at all. I've had to work a lot in Python in the past 6+ months, and I become super confused when I tried making a Python project in my spare time.
I settled on Rye because it just seemed to be the easiest to use.
[0]: https://rye-up.com/
-
Uv: Python Packaging in Rust
I think Rye actually does handle this mostly correctly (as the sibling comment said). I got through some of it here: https://github.com/mitsuhiko/rye/issues/671. I think actually it's very close to what I actually want (maybe not what Armin wants with multiversion).
-
RustPython
Rye[1] is an all in one manager for python projects. Including the python versions and virtualenv, pip etc etc... It seperates tool deps from app deps. Its all configured through a pyproject.toml config file.
Its still new but works well. I'm transiting to it from an unholy mess of pyenv, pip installs and other manual hacks.
If you're starting a new python project that is more than just a straightforward script I'd use Rye from the get go.
[1]https://rye-up.com/
- FLaNK Stack 05 Feb 2024
-
Rye: A Vision Continued
Your first comment irked me because it adds zero value to the discussion. You lazily threw out XKCD 927 which the Rye author explicitly mentioned themselves.
If you click into their link "Should Rye Exist" [1] you'll see that XKCD 927 is literally the first sentence and full width image.
[1] https://github.com/mitsuhiko/rye/discussions/6
-
iJustWantAStableExperience
Try Rye.
-
Poetry: Python Packaging and Dependency Management
Since this is a discussion on dependency management in Python - does anyone use rye [0] regularly now? I'm interested in using it but want a little more social validation before I try - some issues with package managers only appear after you've invested considerable time.
[0]: https://rye-up.com/
-
Why not tell people to “simply” use pyenv, poetry or anaconda
The short term solution is "relieving the packaging pain" link in the article.
The long term solution is described in the "What a solution could look like?" section of https://www.bitecode.dev/p/why-is-the-python-installation-pr...
The community is buzzing with attempts to fix those issues this year, so I’m hopping those posts will become obsolete one day.
Flask’s author is attempting something interesting with rye: https://github.com/mitsuhiko/rye
Trio’s author is drafting a spec for the equivalent of wheels, but for the whole python interpreter: https://github.com/njsmith/posy/blob/main/pybi/README.md
Not advocating to use them right now, but the fact is bootstrapping Python is finally acknowledged as one major cause of packaging issues and a priority to solve.
-
Show /r/rust: self-replace, a create to self-delete and self-replace binaries on Mac, Linux and Windows
I'm building a package manager for Python (Rye) in Rust and it is modeled after cargo and rustup. It like rustup manages itself. This means it has commands such as rye self update which downloads the latest version and swaps itself out. Likewise there is rye self uninstall which uninstalls rye itself.
python-build-standalone
-
Mise is a polyglot tool version manager
It also replaces "just" as a task manager for me which is very pleasant.
The fact that the python plugin uses precompiled Python binaries by default instead of building them from source remove common issues I had with the asdf's python plugin at work with missing dependencies.
Just so you know, I encountered two little quirks that needed a fix:
- [Backspace Key Doesn't work in Python REPL](https://github.com/indygreg/python-build-standalone/blob/mai...)
-
Pyenv – lets you easily switch between multiple versions of Python
These builds are an alternative: https://github.com/indygreg/python-build-standalone
Those are what Rye and hatch use.
Drawbacks: late availability of patch versions, various quirks from how they are built (missing readline, missing some build info that self-compiled C python modules might need.)
-
Show HN: Pywebview 5
Bundling Python isn't too bad if you find the right tools for it.
I really like https://github.com/indygreg/python-build-standalone and https://github.com/indygreg/PyOxidizer
A bundled, built standalone Python can be 16 to 32MB (including the full standard library, which you can strip down to just the bits you use to save size). Not tiny, but probably not worth switching programming languages over.
-
ModuleNotFoundError, but it's there
I'm trying to build a "portable" Python package based on those available from https://github.com/indygreg/python-build-standalone/releases.
-
Briefcase: Convert a Python project into a standalone native application
I'm a huge fan of https://github.com/indygreg/python-build-standalone which provides Python builds that CAN be moved around and work independently of any other Python installation.
I used that for my own Python+Electron app, which I wrote about here: https://til.simonwillison.net/electron/python-inside-electro...
-
alternative to poetry/pip/pipenv/pyenv/venv/virtualenv/pdm/hatch/…
I used to build my own Pythons that are the same everywhere, now I use indygreg's Python builds. Rye will automatically download and manage Python builds from there. No compiling, no divergence.
-
As if there weren't enough packaging tools already: mitsuhiko/rye: an experimental alternative to poetry/pip/pipenv/venv/virtualenv/pdm/hatch/…
One interesting tidbit is that it completely ignores your system Python installations, and instead uses precompiled installations of Python by indygreg from PyOxidizer. This means you don't have to deal with installing Python. It just auto downloads the right builds.
-
How to install any version of Python on Northeastern's Linux server
wget https://github.com/indygreg/python-build-standalone/releases/download/20220630/cpython-3.10.5+20220630-x86_64_v3-unknown-linux-gnu-install_only.tar.gz -O - | tar -xz && mv python PortablePython
-
Switching from pyenv, rbenv, goenv and nvm to asdf – yujinyuz
The lack of Ruby support instantly rings an alarm for me because CPython (on POSIX) also is not relocatable, but is listed as support. Turns pit Hermit is actually using a third-party build script[1] instead of the official one. While the python-build-standalone project is quite awesome and indeed is useful for a lot of things, it has enough quirks I would recommend against any generic package distributor to advertise as Python for general use. This in turn makes me lose most confidence on Hermit, unfortunately.
Be careful if you’re also interested in Hermit. These kinds of things bit you up way down the road when you least expect them to.
[1] https://github.com/indygreg/python-build-standalone
-
How to make sure a python program runs on a computer that might not have internet connection to download the external libraries used?
If you really want to be sure, you can download an install_only standalone Python build from https://github.com/indygreg/python-build-standalone/releases and install the libraries with the included pip. Then just tar it again to archive it, and use the included python to run your project. The downloaded wheel you get with pip wheel may depend on the Python version so you just save the wheels you must make sure the Python point version is exactly the same.
What are some alternatives?
uv - An extremely fast Python package installer and resolver, written in Rust.
iron.nvim - Interactive Repl Over Neovim
huak - My experimental python package manager.
pyenv - Simple Python version management
mise - dev tools, env vars, task runner
eclectica - ☀️ Cool and eclectic version manager for any language
mamba-how-to - Using Mamba-forge for Python environment management
semver - Semantic Versioning Specification
poetry-plugin-export - Poetry plugin to export the dependencies to various formats
Visual Studio Code - Visual Studio Code
zpy - Zsh helpers for Python venvs, with uv or pip-tools
evcxr