@ketozhang By definition [project] implies building wheels. It is not a limitation of Rye or any other tool. This is the specification. There are a bunch of discussions and even at least one PEP in the works to either loosen up this restriction or provide an alternative solution to cover the use case of projects that are not meant to be built into a wheel.
If I am were to implement a project manager, I would definitely have to make a conscious choice to interpret [project] conservatively (wheels-only) or rebelliously (accommodates non-package). We do see existence of both PDM supports the latter (Poetry as well with their own table) then Rye and Hatch supports this using environment/dependency groups.
—if Rye takes the project table for wheels-only stance, then unfortunately it’s not the tool I can put confidence in to integrate with my (and my team’s) workflow. Please take this as a feedback & feature request .
@ketozhang I should have said this in my previous message: Note that I do not speak for Rye or any other project, I only stated what I have understood from the state of things and I may well have mischaracterized things. In other words: Do not take what I wrote for granted.
I think in part that is because “the spirit of open source” has in general not been strongly correlated with “satisfying end users’ desires”. That’s not to bag on open source as it’s done a lot of good for the world, and I’ve actually moved more towards using open source software over time. But it can be a hard sell for many users because there are a lot of open source projects out there that prioritize meeting their developers’ needs rather than their users’.
However, I don’t agree that “open source” has to imply a dizzying maelstrom of tiny tools. And centralizing focus on a main supported toolset doesn’t need to prevent anyone from creating specialized tools too. I see it as more just “raising the floor” of tool convenience, while not lowering the ceiling.
Things like Linux distributions, for example, have come a long way in this regard[1], from the old days when it was nearly impossible for anyone who wasn’t a tech nerd to use them, due to abstruse install mechanisms, hardware incompatibilities, and barebones setups that required the user to painstakingly install and configure everything. But now a system can be up and running smoothly without technical expertise, you even have stuff like the Steam Deck shipping Linux to gamers — but there’s still Arch for those who want to go hardcore. I don’t see these things as opposed to open source; rather they’re success stories.
The thing is that, for many users, Python is already inherently centralized around python.org and the distributions it provides. As I’ve suggested multiple times, if we want to go the route of decentralization, the way to do that would be to state loudly and clearly on python.org that end users should look elsewhere for documentation, tools, and maybe even to install Python. But if we accept that python.org is going to be the central point of reference for the Python world, I’d say it makes sense to have it fill that role in a more comprehensive way.
I hear this is the year of Linux on the desktop ↩︎
Rye does not change anything about how pyproject.toml or pip works. The reason you get this error is because that’s just how these tools today build packages.
It’s not about building the project. Its about Rye supporting projects that don’t intend to be built and not have their source code installed: application projects.
Here’s an example I’m sure you can relate to. How does a Flask user with just a single app.py file is supposed to use Rye? Are they forced to make a package directory with mypkg/views.py?
To be fair, though, that’s not a question that’s unique to Rye. You can ask the same of poetry, hatch, PDM, or any of the “workflow tools” that exist. You can even ask it of the low-level standards underpinning those tools - where do I store the definition of my virtual environment? How do I share my project with other users?
I agree 100% that Python should have better support for such projects - I’ve been saying this for years. But it’s more a question of “Rye is no better than the rest of the packaging ecosystem in this regard”.
Yeah thats right, every workflow tool has to face this problem. Some have workarounds. I’ve asked Hatch for the same. I did not intend to imply that Rye did something wrong for following pyproject.toml spec’s status quo.
I do mean to push Rye to explore options for application projects. Given the recent news of uv implementing non-standard features of pip (e.g., overrides), now I more strongly push Rye to consider solutions for application projects not yet a standard.
FYI pip doesn’t support overrides, I have previously proposed overrides to pip in the same way uv has implemented it, but as far as I’m aware no consensus or work had ever been done for pip to implement it.
However, pip and uv both support constraints, in some form, which is an installer feature and not a defined standard.
Hatch environments allow you to specify an exact Python version which allows for projects to be used like applications without requiring the build table. There might be an issue where the project table is still erroneously looked at which I might have to fix, I can’t remember if I did that yet.
To be fair, many installers and workflow tools have one form of constraints or another. Sometimes advertised as lockfiles. There’s a rejected standard for those. You can make them yourself, which is tool-specific. For example, pip-tools can provide building blocks for generating such “DIY lockfiles”, which is what Rye seems to be wrapping in a more high-level interface/workflow.
Though, I’m personally more worried that common underlying concepts aren’t relayed the through shared definitions causing people to misunderstand what they actually need. Hopefully, PEP 735 will address at least some of the interoperability shortcomings and perhaps close that gap of supporting environment definitions for apps too…
This is getting significantly off topic, but contraints files are significantly more powerful than lock files, they let you direct resolution with an unknown solution, lock files you must know the solution upfront.
Rye doesn’t care. You can set it up in whatever form you want. The recommended default is the structure it generates but rye doesn’t force you in any form.
This is the second time I have received this concept today. @ofek also linked an article to me that said the same. I was unaware that there are people that build applications in a way where the application itself is not a pyproject. I do not really understand why this is done to be honest. That seems counterintuitive to me and not in line how other ecosystems do it.
There’s been a lot of discussion over the past several months about different use cases, but one straightforward example is that people may want to distribute applications in a way that doesn’t require the end user to have Python installed, or even to know that Python exists.
I agree with that, but I do not understand why that implies not having a pyproject.toml. I also redistribute Rust and JavaScript code, but in all those cases those are crates or javascript packages. Why would that situation be different in Python? I do not quite see anything that stands in the way of treating this just as a wheel too that just happens to also be built into a .exe or anything else.
Projects building an application via something like PyInstaller won’t use or need a pyproject.toml, as that’s not what PyInstaller uses to define how to build the application.
Projects built and distributed as zipapps will not be structured using pyproject.toml, will not be built using a build backend that creates wheels, and the build will in fact often simply be a custom script.
Projects that aren’t intended for distribution (such as data analysis projects) will often have deliverables that aren’t “python applications” at all - for example, the deliverable may be a graphical report, or a Jupyter notebook, or a summary data set as a CSV file.
The whole “projects that don’t produce a wheel” question has been discussed a lot here recently. It’s quite possible that if you don’t follow the Packaging topic you’re not aware of it, but it’s definitely an important use case, and one that the Python packaging ecosystem currently doesn’t serve at all well.
I don’t know how these types of projects map to other ecosystems. Compiled languages like Rust, go or C++, don’t really have the concept of anything like a zipapp (the nearest I can think of is Java’s executable jars, or TCL’s starpacks). And the distinction between building libraries and building applications that exists in Python doesn’t really exist in those languages.
Compiled languages don’t really support data analysis style projects except in the sense of “you can build an application that does some or all of the analysis”. Maybe a better ecosystem to look at for this would be something like R, but I know very little about that.
.
That’s not to bag on open source as it’s done a lot of good for the world, and I’ve actually moved more towards using open source software over time. But it can be a hard sell for many users because there are a lot of open source projects out there that prioritize meeting their developers’ needs rather than their users’.