3 ms·
As long as you don’t care about Python versions I too find pip + venv sufficient. But there is no way for you to define which Python version your project is bu
by wodenokoto 2y ago
As long as you don’t care about Python versions I too find pip + venv sufficient.
But there is no way for you to define which Python version your project is built against.
If you’re building a package you probably need to test against multiple versions. If you are building a “project” that isn’t an installable, distributed package but a bunch of code that is shared with a few developers and does something (run a machine learning model, push itself to a cloud function, generate a report) you probably want to target 1 and only 1 Python version.
As for the mono repo approach are you suggesting to copy paste numpy and pandas into the repo?
- globular-toast 2y agoWhat you mean by "project" is a service. A service includes the Python interpreter. Choosing and provisioning the interpreter seems out of scope for pip or any other Python-specific tooling IMO. What if your service needs another interpreter like Ruby, or a database, message broker etc? Your Python tool won't help with that. This is what docker, and higher-level orchestrators like docker compose and kubernetes, and pyinstaller are for.
- wodenokoto 2y ago> Choosing and provisioning the interpreter seems out of scope for pip or any other Python-specific tooling IMO. It's in-scope for Rye and hatch. And I agree with that choice. Choosing a python version is as integral a dependency as choosing a version of numpy.
- globular-toast 2y agoSure, but you can only document that choice in your pyproject.toml, which is well-established. You have no idea how someone is going to provide that interpreter. You don't know what OS or how to provision an interpreter. If you are the person provisioning that interpreter then just use the tools you already know, not yet another tool to do basic stuff like install an interpreter.