-
Notifications
You must be signed in to change notification settings - Fork 3
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
Cache templates #6
base: cache-task-not-lighthouse
Are you sure you want to change the base?
Cache templates #6
Conversation
We support Python 3 now. Use that in the default instructions, but explain that `python2` or `python` will work in its place.
These overrides are very outdated. (Haven't been updated since the day they were added, back in 2014.) Even with these applied, Lintian still prints many warns/errors. I think no-one has been running Lintian against the .deb package for a while now.
Use this to find python for the verify-machine-requirements.js script.
.python-version specifies which version(s) of Python are in the PATH, and which version runs when you run the python, python2, or python3 commands. That said, it is overly specific for this repository's needs. In order to specify any version, you must enter it down to the patch level, e.g. 3.8.2; Major-minor versions aren't allowed, e.g. 2.7 If users want to add such a file on their own machines, they may... But it's unneccesary for this repository to ship this file as if there were specific "correct" versions of Python to use. Any Python 2.7.x or 3.5.0+ will work at the moment. There are other checks elsewhere in the project, such as in script/bootstrap. These should be sufficient to inform users which Python versions they can use. node-gyp will also tell you.
Log which Python commands were tried, and the results, if no usable Python was found. Useful for debugging failures.
Python 2 is officially end-of-life. We can use Python 3 now.
in script/lib/verify-machine-requirements.js
Make sure a previously found version isn't erroneously logged, by clearing the "fullVersion" variable before each new check.
no need to use path.basename
Co-authored-by: Sadick <[email protected]>
…_release no PR triggers on release builds
Miscellaneous python3-related updates and fixes
Faster atom.packages.getAvailablePackages
@DeeDeeG Please merge this and then rebase it or use git cherry-pick to only bring the last commit. Edit your previous PR to upstream to include the new change. |
121c8d7
to
b60ba40
Compare
Can we remove the Edit: And maybe we should include the RestoreKeys stuff? https://docs.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops#restore-keys |
No. Agent.OS gives different strings such as |
Pardon me for not understanding: Why do we want the nicer string? Is it for display? Separate question: Why do we need it in the cache identifier, when I believe the effect is the same if no parameters are used. But it takes less code and might be more readable or simpler to maintain. |
No problem. That is interpolated in the file names
|
Right, okay. Thanks. I'll make sure that's in the PR. If you don't mind I'll just update the current one instead of closing/opening a new one? |
Sorry. I fixed it. |
No worries, thanks. 👍 |
This is part of the PR at upstream now: atom#21057 By the way, my PR to upstream is off of another branch: https://github.com/DeeDeeG/atom/tree/ci-use-official-cache-task |
Thanks! |
No description provided.