rye VS Graal

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

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/

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).

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/

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

Try Rye.

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/

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.

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.

Contrary to what vocal Kotlin advocates might believe, Kotlin only matters on Android, and that is thanks to Google pushing it no matter what.

https://spectrum.ieee.org/the-top-programming-languages-2023

https://snyk.io/reports/jvm-ecosystem-report-2021/

And even so, they had to conceed Android and Kotlin on their own, without the Java ecosystem aren't really much useful, thus ART is now updatable via Play Store, and currently supports OpenJDK 17 LTS on Android 12 and later devices.

As for your question regarding numbers, mostly Java 74.6%, C++ 13.7%, on the OpenJDK, other JVM implementations differ, e.g. GraalVM is mostly Java 91.8%, C 3.6%.

https://github.com/openjdk/jdk

https://github.com/oracle/graal

Two examples from many others, https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futurama Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources!

https://github.com/oracle/graal/tree/master/truffle

Disclaimer: graalvm dev here.

That's pretty interesting. It's not as aggressive as Bee sounds, but the Espresso JVM is somewhat similar in concept. It's a full blown JVM written in Java with all the mod cons, which can either be compiled ahead of time down to memory-efficient native code giving something similar to a JVM written in C++, or run itself as a Java application on top of another JVM. In the latter mode it obviously doesn't achieve top-tier performance, but the advantage is you can easily hack on it using all the regular Java tools, including hotswapping using the debugger.

When run like this, the bytecode interpreter, runtime system and JIT compiler are all regular Java that can be debugged, edited, explored in the IDE, recompiled quickly and so on. Only the GC is provided by the host system. If you compile it to native code, the GC is also written in Java (with some special conventions to allow for convenient direct memory access).

What's most interesting is that Espresso isn't a direct translation of what a classical C++ VM would look like. It's built on the Truffle framework, so the code is extremely high level compared to traditional VM code. Details like how exactly transitions between the interpreter/compiled code happen, how you communicate pointer maps to the GC and so on are all abstracted away. You don't even have to invoke the JIT compiler manually, that's done for you too. The only code Espresso really needs is that which defines the semantics of the Java bytecode language and associated tools like the JDWP debugger protocol.

https://github.com/oracle/graal/tree/master/espresso

This design makes it easy to experiment with new VM features that would be too difficult or expensive to implement otherwise. For example it implements full hotswap capability that lets you arbitrarily redefine code and data on the fly. Espresso can also fully self-host recursively without limit, meaning you can achieve something like what's described in the paper by running Espresso on top of Espresso.

I'm also using GraalVM if that's of any help.

Quarkus is one of Java frameworks for microservices development and cloud-native deployment. It is developed as container-first stack and working with GraalVM and HotSpot virtual machines (VM).

Apologies, I didn't mean to imply DCEVM went poof, just that I was sad it didn't make it into OpenJDK so one need not do JDK silliness between the production one and the "debugging one" since my experience is that's an absolutely stellar way to produce Heisenbugs

And I'll be straight: Graal scares me 'cause Oracle but I just checked and it looks to the casual observer that it's straight-up GPLv2 now so maybe my fears need revisiting: https://github.com/oracle/graal/blob/vm-23.1.0/LICENSE

> to be compiled to a single executable is a strength that Java does not have

I think this is very outdated claim: https://www.graalvm.org/

https://github.com/oracle/graal/issues/7182