Add Python imports sorter to CI and supply-chain review #48
Conversation
This patch applies effects of the following patch that adds `isort` to CI. The patch-ordering is because adding to CI first would cause CI to fail on finding files need to be re-formatted by `pre-commit`. This also separates manual changes from automated changes. Disclaimer: Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose. Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
This patch draws on Cyber Domain Ontology deployments from the noted PRs. References: * casework/CASE-Utilities-Python#37 * Cyber-Domain-Ontology/CDO-Shapes-Example#1 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
Text adapted from contributions to `case-utils` by @kchason. Disclaimer: Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose. References: * casework/CASE-Utilities-Python#37 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
|
This PR is ready for review and merge. |
I tried separating the changes into commits that were manual vs. commits that were automated effects. Sorry, I forgot to mention the right tab to look at first was the "Commits" tab, not the "Files changed" tab. I put this PR in first because it's adding I will add Black in another PR after closing PR 45 tomorrow morning. I'm pretty sure Black would cause a few code conflicts with that PR while it's in-flight. I hadn't heard of |
|
Flake8 is a linter, I think, and not a reformatted…
…On Mon, Jun 24, 2024 at 12:13 PM Alex Nelson ***@***.***> wrote:
Wow. A staggering number of changes. isort really has fun with this. If
you are going to do this, why not just go full blown autopep8
<https://pypi.org/project/autopep8/> or black
<https://github.com/psf/black>?
I tried separating the changes into commits that were manual vs. commits
that were automated effects. Sorry, I forgot to mention the right tab to
look at first was the "Commits" tab, not the "Files changed" tab.
I put this PR in first because it's adding pre-commit and pre-commit
maintenance logistics, and isort is the least-code-touching reviewer
among the ones I was going to import from the CASE repositories' practices.
I wanted this PR to check in on whether this pre-commit semi-automated
maintenance practice is OK. I've found running pre-commit autoupdate
nightly and keeping the pinned version up to date is a little too frequent
for my maintenance preferences. Updating the pinned version whenever it
changes code keeps pre-commit from mixing in unrelated effects to
incoming contributions.
I will add Black in another PR after closing PR 45
<#45> tomorrow
morning. I'm pretty sure Black would cause a few code conflicts with that
PR while it's in-flight.
I hadn't heard of autopep8. The CASE repositories happen to use flake8.
I'll try those as I add Black.
—
Reply to this email directly, view it on GitHub
<#48 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMFHLGIQ6UQN4E2HTIG3STZJBAT3AVCNFSM6AAAAABJWZBPH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBWHEZTINBVHA>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
This PR adds and applies Python code-formatting to CI and adds a supply chain review step to keep the pinned formatter references "reasonably" up to date.
The extra logic in the
check-supply-chain-pre-committarget will update the version-pin if an update is available, but will not raise a notice unless updating the tool version would induce a change in any of the Python files. (Changes in the Python files are checked with the pinned formatter version in CI.) These lessons were learned betweencase-utilsPR 37 and CDO-Shapes-Example PR 1.The new
maketarget that creates a Python virtual environment, dedicated to the user's current repository clone, does this in order to avoid a Git logistical issue ifmake cleanis run. (Described further incase-utilsPR 37.)Tools noted in the referenced PRs will be added in future PRs.
isortis added as the first tool in order to avoid code conflicts with in-flight non-formatting revisions in other PRs.Impact of merging this PR will be:
CONTRIBUTE.md) should see instructions to runmake, or otherwise installpre-commitin order to handle now-delegated code formatting decisions.make ; git commit --amend; git commit -m "Format"in the user's branch should provide a pushable patch atop the submission (noting the middle command fails, perpre-commit's execution style).References
Disclaimer
Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose.