New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support flexible patch version syntax to allow for automatic Python updates #913
Comments
Heckin yes. Not the next thing on my list, but on the list. |
I could probably help you with a patch given the exact place where Python selection happens. |
@abitrolly Hi! Thank you for filing this. I 100% agree this is something we should support. Whilst some projects will always want to specify an exact Python version to ensure determinism/allow control of when the upgrade occurs, there are likely many more that would like to not have to think about patch updates and have them be performed automatically. Some thoughts that came to mind:
To try and answer these, I took a look at what other tools/services use currently: Pyenv
Python Poetry
Pipenv
Travis CI Python
Circle CI Python
Azure Pipelines
Netlify
Docker Hub Official Python images
Given the above, I think it's best if we:
|
I see not problem to support them all, but I would leave python- prefix intact, because there are also alternative interpreters like
|
On the second thought a separate component that can parse the requirements from all these platforms and autodetect best Python version given priority list (also explaining its process and selection logic) would be beneficial not only for Heroku. |
Tracked internally at W-7671453. |
Yes, please! |
So I've been revisiting this topic (ways in which the Python version could/should be specified for Heroku apps in the future) as part of the CNB for Python work, Edit: Since this was posted, pyenv has added support for X.Y style version ranges to The options that we may want to consider (we'd likely need to support several from this list): A) Use
|
We are, of course, for |
So I think it's inevitable that we support package-manager specific constructs (eg Poetry's), the decision here is more:
|
I don't think that one chosen way will work. It should be a priority list. The promise of buildpack is that it can build you project automatically. Otherwise it is not really different from going Docker/Kubernetes/OpenShift way.
If there is a priority list, then I don't see any problem to use latest available version that fits For the spec it would help dividing A-G into priority groups. |
@abitrolly Yes, that's exactly the intention - to support several options and to have an ordering of precedence. The point (as discussed above) is:
The A-G list is a starting point to aid that decision, not mutually exclusive options. |
This is a good list. My first choice would be to support B only. Having a cascading list of places to try is clever/convenient, but I think makes things more confusing for users. The way Node/npm/yarn is handled with
I can see Another benefit of B is that it can be used to not only specify the Python version, but also, To address the cons of this approach:
This is a compelling argument for using A, but the cons mentioned there outweigh the benefits. Being able to specify all tooling (Python, pip, etc) versions in one place is worth the trade-off.
Naming is always hard. That shouldn't be a deterrent for the best solution 😄 |
I'll update the list above to make this clearer - but my main concern about the naming if adding a
ie: The way PEP518 is written, it doesn't allow tools from different vendors to share the same namespace. And avoiding yet another Heroku-ism was something I was hoping to avoid this time around :-) However since trying to publish a package called |
Following PEP518 seems like the right thing to do. I like not having it tied directly to Heroku or Buildpacks so it could possibly become a standard. |
In the time since the analysis in #913 (comment) occurred:
As such, this resolves a number of the issues with the (There will of course still need to be package manager specific file support, such as parsing |
@edmorley I appreciate the amount of thought you put in this issue, but I still don't see any actionable items since I opened it. It is about time for me to stop licking this cookie and go find a job. If, however, Heroku has a process to hire me as a contractor (which is doesn't), I could spent a few week to collaborate on a use case test book. Which, QA-style, will allow anybody to quickly go through the cases to validate what we are not breaking anything by switching from runtime.txt to .python-version. If you've already decided it will be more beneficial to deprecate |
@abitrolly Hi! This issue is not blocked on you, and I'm not expecting you to work on it. Whilst this issue was initially filed about runtime.txt, I've been treating it as a general "support flexible versions" issue (that is considering all potential solutions) - I've morphed the title to reflect this. The reason for my most recent comment was that I received an email notification for the pyenv issue being closed as implemented, and I wanted all context about Python versions to be contained here ready for when I revisit the topic. The discussion/comments here will feed into the design of the Python Cloud Native Buildpack, which I'll (finally) be able to have time for again soon. |
There are already a couple of buildpacks supporting Python, some supporting Buildpacks based systems can use Maybe it is not the role of the buildpack to choose Python version at all, because package authors know better, and they most likely don't be too pleased to have yet another place to configure Python. |
Pinning Python runtime on Heroku prevents it from getting security updates.
The secure way is to allow any newer patch version to be installed. Proposed syntax.
The text was updated successfully, but these errors were encountered: