You’re hardly an average user, so I’m taking this with a huge grain of salt. Could you elaborate where the user feedback came from and where the feature was requested?
I’m uncertain if it’s considered bad, but it’d be interesting to understand what’s wrong with a pip requirements file or
pyproject.toml in this context. Is that what you mean with “very bad”? Are you suggesting that the user experience with those real solutions is bad and we should improve it, by adding yet another way?
Sure, off the top of my head I can only think of making existing solutions “official”, mostly centered around my perception that this is an issue of users struggling to turn their one-off-scripts into executables or at least easy-to-execute CLI scripts.
Essentially, I think this is an application packaging issue in disguise, e.g. to turn a script into an executable. We could improve this by promoting projects like pyinstaller and PyOxidizer that bake in the dependencies. Could the PEP describe a standard way to do that, where we reuse
pyproject.toml? It might solve the dependency caching problem that PEP 722 tools will surely have to face on consecutive runs.
That’s… not what I was said. I’m saying that telling them for this use case there is a slightly different way to define requirements via docstrings, instead of the many other ways, is not going to make it magically easier, but just increases the cognitive effort needed to conduct Python packaging. Yep, I’m basically calling this a case of xkcd://927. Could you add a comparative analysis to the PEP showcasing what people currently do?
Imagining the PEP goes ahead:
- Would it essentially support all of pip’s requirements file syntax (and/or PEP 508) in the docstring of files (including pip’s hash-checking mode)?
- Would this also be supported in more complex projects that are not single-file-scripts (would it be allowed in
- Are there other features from
pyproject.tomlthat would become needed for real world usage (e.g. optional dependencies)?
Good call-out, I didn’t have my conda hat on, in this case, but it’s a good question. Going to have to think about it. My feedback was purely focusing on the Python packaging.
Well, I’m for progress, for the record, in case that is in doubt. I’m submitting that adding yet another way to specify requirements is not progress but only distraction and more choice doesn’t equal a delightful user experience.
I definitely would say this PEP might harm what we do in the area, by not making it more obvious what users should do to package their scripts (which implies best practices around versioning etc). As such, I would strongly encourage presenting the PEP draft to real world users (not you!), if that would help them before we go ahead.
No apologies needed, as always, I’m providing this with an open mind and am looking for more clarification, obviously you’ve put lots of thoughts into this proposal.
That said, I wasn’t aware that you had argued for years about this! It might be helpful for the proposal if you’d add some of the past feedback you’ve received to the proposal and how the historic conversation around this topic went?