Why we do not store information about python implementation in Pipfile or pyproject.toml?
As far as I know we do not store in metadata this information. Maybe we should change that, in my current project I want to force using only PyPy.
Why we do not store information about python implementation in Pipfile or pyproject.toml?
As far as I know we do not store in metadata this information. Maybe we should change that, in my current project I want to force using only PyPy.
Very interesting question!
I did some searching, though it’s a bit hard to find good search terms, and I wasn’t able to find any discussion of this.
The answer to “why” might simply be that no one has thought of or asked for this feature.
For a library, why would you want to block people using other Python implementations from using it? For a script (or application), why not just put the interpreter to use into the shebang line?
I guess I’m not seeing why this would ever be useful. Maybe you can explain why it matters to you that your users have to use PyPy?
Is it something that could/should be solved by trove classifiers?
@pf_moore I am developing my application in PyPy and it will be running in PyPy on production. I do not want developers to introduce bugs related to following differences: Differences between PyPy and CPython — PyPy documentation
For library, hmm, for example you have library (especially some internal) that is ready to use and tested only for particular implementation, and you want to mark it.
Surely you can simply document the correct development environment to use in that case? This sounds more like a development workflow issue (or possibly a developer management issue) than a package metadata one. And I agree with @sinoroc, if you want to specify this at the metadata level, classifiers are the appropriate way - they don’t force anything, but they do declare explicitly what implementations you are willing to support.
Also, in additional to there already being metadata (via classifiers) to signal the implementations your package supports, you could probably also use wheel tags to explicitly restrict it to only being installed on PyPy, at least from wheels, and/or include setup.py
logic or (preferred) a backend setting or plugin to warn or error on attempting to install into a non-PyPI implementation.