An opinionated Python package/application template repository, with SLSA and SBOM support built in, enabled for security scanners, code linters, typing, testing and code coverage monitoring, and release automation for reproducible builds.
License: MIT License
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
We need to revisit how to trigger the CI checks based on the events (pull_request vs. push), branches (main, staging, and the rest), and matrices (e.g., OS and Python versions).
Potentially we could remove tox, but then it might make sense to enforce the CI tests on every push event for all the branches. Currently CI tests is only enabled for push to main and pull_request for other branches.
We also need to document the branching model and how it affects running the CI checks.
It would be very useful to have an action, triggered by a ReleaseEvent, which creates new PRs for a number of “registered” repositories with the changes of the release. Here, registered repositories can be hard-coded into the action as a list.
In that context, it would be useful to prevent registered downstream repos from modifying certain files (e.g. the Makefile) because those changes should be applied in the template repo and then waterfall downstream. (Further discussion here or git diff’s filter option.)
@behnazh, if I understand you correctly in related issue #25 then we need a scripted build of sorts reach SLSA Level 1 for this repo. For Python packages (What about applications?) that’s described on the Creating Built Distributions — is that what you mean?
It sounds like the script itself is required, but not the built artifact, e.g.
#!/usr/bin/env bash
python setup.py bdistwhich would create e.g. a dist/package-1.1.2.macosx-10.14-x86_64.tar.gz artifact; or using the sdist to create a dist/package-1.1.2.tar.gz artifact. (See also the setuptools documentation.)
I noticed in another project that pip config can misbehave if a local configuration doesn’t exist. For example, the aws command ran inside of a virtual environment but still modified my user settings and ignored the virtual environment (issue aws/aws-cli#7085). This led to quite a bunch of other issues with other virtual environments because those other virtual environments now inherited the settings.
So it would probably make sense to add a
touch .venv/pip.confat the end of our venv recipe:
python-package-template/Makefile
Lines 45 to 58 in e5a047f
to create an empty and local configuration, which pip will then find before the user’s configuration.
Suggest adding template copyright information at the top of all the python code files, or possibly all the code that looks something like this:
"""
Filename:
Copyright (c) 2021 - Present
All rights reserved.
"""
This issue is related to #31 (and discussion in #30) and the subsequent PR #35.
Turns out that with today’s minor version bump to v1.1.1 the UPSTREAM_CHANGELOG.md was not updated, and I can’t find an indicator as to why in the Action log.
Looking and testing the related code works locally because pathlib.Path() follows symlinks transparently. More investigation required, and I might consult with @relekang as well regarding details of the python-semantic-release package.
Previously, bump commits like ba77a96 would have an additional body, e.g.
commit ba77a96deec32e351ecd931e2c15843522be36ad (tag: v2.0.0)
Author: github-actions <[email protected]>
Date: Wed Jul 6 08:42:35 2022 +0000
bump: release v2.0.0
Automatically generated by python-semantic-release
whereas now that body doesn’t exist, e.g. commit f602cb4:
commit f602cb4d81012453212cb3017a8ae2549347a4eb (tag: v2.3.1)
Author: jenstroeger <[email protected]>
Date: Fri Aug 26 06:37:50 2022 +0000
bump: release 2.3.0 → 2.3.1
I think it would make sense to add a body text again.
Based on this conversation — add a Github Action which runs pre-commit autoupdate and, if hooks need updating, opens a PR accordingly. Something like explained in this blog.
Tracking issue for:
I believe this is due to the recent change of .yml to .yaml files.
Tracking issue for:
@jenstroeger I wonder if this alert is a false positive? We need to give contents: write permission to relekang/python-semantic-release to create the release commit, right?
Currently the package uses pip and Python’s setuptools as described in Packaging and distributing projects. However, problems with recursive dependency checks, deep version collisions, or cumbersome pinning make working with pip somewhat unreliable.
Alas, a few minutes ago Python 3.10 was released as stable and perhaps we should make that the minimum required Python? The feature list certainly is exciting 🤓
Based on the community profile a few files are missing:
Consider adding those files, and perhaps go browsing through the Customizing your repository sections to find more useful settings.
There’s been much discussion in the community about the structure of a Python project, see for example this blog Testing & Packaging by @hynek.
And so, perhaps it would make sense to introduce a dedicated src/ directory for the package code itself 🤔
A regression introduced with PR #27: the git hooks didn’t run their tests over the package source anymore because the source’s moved into the src/ folder.
For example,
python-package-template/.pre-commit-config.yaml
Lines 40 to 42 in eaa6a60
uses a regex for the files entry and matches that regex against path names. That regex wouldn’t match anymore for the new src/package/… paths and therefore files wouldn’t be picked for the hook anymore. Not sure that’s actually fixable on the pre-commit side because the matched list of files is not empty — it’s just not complete either 🤔
I also noticed that mypy would generate an error
tests/test_something.py:5:1: error: Skipping analyzing "package.something": found module but no type hints or library stubs
tests/test_something.py:5:1: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
Found 1 error in 1 file (checked 2 source files)
which can be fixed by adding mypy_path to the configuration.
With PR #259 in mind, this change might be already obsolete:
diff --git a/pyproject.toml b/pyproject.toml
index bcd8ee3..29d4217 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -189,4 +189,4 @@ version_variable = "src/package/__init__.py:__version__"
upload_to_pypi = false
commit_subject = "bump: release v{version}"
changelog_file = "CHANGELOG.md"
-build_command = "pip install 'flit >=3.2.0,<4' && flit build"
+build_command = "pip install 'flit >=3.2.0,<4' && flit build --setup-py"The trusted builder calls
python-package-template/.github/workflows/build.yaml
Lines 72 to 76 in 1cd7aa0
which in turn does already generate the setup.py for the source distribution:
python-package-template/Makefile
Lines 127 to 137 in 1cd7aa0
When our release.yaml creates a Release on Github using gh release:
python-package-template/.github/workflows/release.yaml
Lines 122 to 126 in f41b0e6
we enter a race condition where the Github release event fires before this current workflow finishes. Which can become an issue because other actions that trigger on that event (like our release-notification.yaml or PR #224 PR #396) may want to access the artifacts attached to this workflow… and that fails because this workflow is still running.
I wonder if instead of running on the release event we should use the workflow_run event:
on:
workflow_run:
workflows: Check and Release
types: completed
branches: main
jobs:
some-job:
if: ${{ github.event.workflow_run.conclusion == 'success' && startsWith(github.event.commits[0].message, 'bump:') }}
...
other-job:
needs: some-job
...@behnazh what do you think?
As per PEP 561 “typing information must be distributed manually”, and mypy uses stub files. More information in mypy’s section Creating PEP 561 compatible packages.
Tracking issue for:
We already use Hypothesis, and there are fuzzers like Atheris and Frelatage that we could consider for fuzzing. However, perhaps we should only mention those and leave it to users of this template to incorporate more diligent fuzz testing?
Tools like Wily and Radon allow to track code complexity metrics, e.g. based on cyclomatic complexity or Halstaed’s complexity metrics. It might make sense to track these (and other?) metrics to measure software maintainability.
In addition, e.g. Bandit or dlint might be useful additions?
Git allows for signing commits and tags, see also the Signing Your Work chapter. Furthermore, twine upload allows for signing packages when uploading them to a PyPI server.
Related to PR #306 and issue commitizen-tools/commitizen#575, I wanted to keep the discussion going on signing and verifying signatures in an automated workflow. Signing commits and tags not only generated by a local user (who needs to sign commits locally) but also generated by the release.yaml Action
python-package-template/.github/workflows/release.yaml
Lines 55 to 60 in f41b0e6
and
python-package-template/.github/workflows/release.yaml
Lines 140 to 145 in f41b0e6
Read the linked issue for more information, and take a look at the How to use GPG key in github actions? Also related is issue actions/runner#667.
SLSA is a promising work that aims at improving the security posture of open source software and protecting against supply chain attacks. I believe this template provides a good opportunity to adopt SLSA. Even though SLSA is still a work in progress, I don't think we should wait for them to finalize the specs, and the earlier we start the better.
The current layout of the repo looks like this, which misses a build step (the quality assurance steps don't modify code, but build does)
To make this template and the repos created from it meet the highest SLSA levels, we need to prepare the repo to meet their requirements. To begin with, I propose to make the repo ready for level 1. This level helps publishing an artifact provenance in a common format, in-toto. For that we need a more explicit build and packaging steps, which developers can develop further based on their needs. This would satisfy the Scripted Build requirement.
Once the repo meets level 1, we can use in-toto to generate the provenance and verify it.
I think there should be separate CHANGELOG.md files for the template and the derived repo's from this template. Could we have a different name like TEMPLATE_CHANGELOG.md and then reserve CHANGELOG.md for the derived packages and repos?
If that's not possible, how can we get the CHANGELOG.md file to have the template's changes segregated or integrated in a way that makes merging the template into derived repos easier.
Noticed when merging changes from this template repo to another repo the Readme.md file is "confusing." I think there should be a Template_Readme.md file where all the relative template readme information is stored.
This allows me to create a new repo from this template and keep the derived repo's Readme file separate, but also allows me to merge changes from this template easily without conflicts.
With PR #208 we moved the package metadata to a declarative approach using the pyproject.toml file. Alas, it seems that Dependabot isn’t able to handle that correctly and so we track their progress in this issue:
Interesting project, I think you've got a pretty good start here, but one thing that strikes me as lacking is a repo-wide view of license management.
Clearly establishing license terms is so important in open-source projects (both for the author(s) of the code, and for anyone who's considering making use of it in their own projects), yet it's often handled haphazardly as an afterthought — or, just as often, not handled at all until someone pesters the maintainer into acting out of frustration. Typically that kind of thing causes problems down the line for someone (probably not the originator of the... "bespoke" license in question).
Adopting a standard for licensing right out of the gate is a simpler, saner solution. And it can be as simple as committing to standard practices defined by something like the Reuse project. Just like most projects will commit to following semantic versioning practices, adopting reuse-verified license compliance requires nothing more than a commitment to put in the work.
Tracking issue for:
I think these environment variables:
python-package-template/.github/workflows/build.yaml
Lines 35 to 36 in 66347c6
python-package-template/.github/workflows/codeql-analysis.yaml
Lines 51 to 52 in 66347c6
aren’t necessary because make setup assumes a venv. The PYTHON environment variable is used only by the make venv goal to pick the Python for the virtual environment:
python-package-template/Makefile
Lines 29 to 42 in 66347c6
As of v2.3.3 of this package template, the pyproject.toml file declares no package dependencies
python-package-template/pyproject.toml
Line 14 in 25c486b
and a handful of optional/extra dependencies
python-package-template/pyproject.toml
Lines 36 to 63 in 25c486b
solely for the purpose of local development and CI/CD. However, it does not declare any optional/extra dependencies which would be considered part of the shipping & deployed package!
And because it does not declare any optional/extra dependencies, the generated release artifacts contain an almost empty requirements.txt file and an SBOM with pinned development dependencies only.
Naturally we want to build more complex packages which may even offer optional/extra dependencies, just like e.g. the Dramatiq or SQLAlchemy packages do. So, the questions that arise now are…
How would that impact the generation of the requirements.txt and SBOM artifacts? Not sure it makes sense to generate build artifacts for all possible variations of a package, nor build artifacts that are all-inclusive? Should we take a “best effort” approach? Or… 🤔
I would recommend that the README file call out that anyone forking/copying this repository disable the windows and macos checking for github actions.
Per this link: https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions
Checking on those two variants is quite expensive on Github actions minutes and $, so I would not recommend it as you can eat through your allocated minutes and money quickly.
This line
can break the workflow if there are no tags set for a repository: the --incremental option seems to require a tag:
> git tag
> cz changelog --dry-run --incremental --unreleased-version "Release Notes"
No tag found to do an incremental changelog
A workaround would be
if [ -z "`git tag`" ]; then \
cz changelog --dry-run --unreleased-version "Release Notes" > dist/RELEASE_NOTES.md; \
else \
cz changelog --dry-run --incremental --unreleased-version "Release Notes" > dist/RELEASE_NOTES.md; \
fialthough I’d prefer to solve this on commitizen’s side, for example by allowing --incremental without tags in which case the entire log should be considered. @Lee-W or @woile, what do you think?
Somewhat related issues with the same error are commitizen-tools/commitizen#297, commitizen-tools/commitizen#463, commitizen-tools/commitizen#529
We have specified this dependency:
python-package-template/setup.py
Line 63 in b36c1d0
whereas the Github action uses this one:
So, the locally installed semantic-release tools may not match the ones used by the Action when running a CI workflow.
I think there are several ways of addressing this:
setup.py. That’ll introduce duplication, though, and feels tedious.setup.py because the tools aren’t used often locally; if they are, a manual installation may suffice.Thoughts?
By default mypy’s incremental mode is enabled, which writes a cache of previous evaluation results. In our Makefile we wipe that cache with make clean
python-package-template/Makefile
Lines 118 to 120 in 4f156fe
Stale cached values have been biting me and others several times now, and I’m tempted to disable incremental mode by default in our mypy.ini:
[mypy]
incremental=FalseThoughts? 🤔
Currently this repository is set up to use Sphinx to build HTML documentation (or whichever other output format Sphinx provides). Considering this repo is hosted on Github, I think it follows naturally that we should be able to generate documentation in Markdown and publish the generated documentation here… 🤔
There are a few tools that generate Markdown from Python docstrings, with or without Sphinx (older Stackoverflow question):
It would then make sense to integrate a “generate documentation” step into our release Action, and either find a way to publish the generated Markup directly into the repository or as a Github Wiki (which is its own repo), or use e.g. the uibcdf/action-sphinx-docs-to-gh-pages Action to publish to Github Pages.
Lastly, perhaps it would also make sense for this repository to opine/dictate a docstring style (e.g. based on Google’s Style Guide) and check docstrings using Sphinx’s Napoleon extension)?
Tracking issue for:
I suspect Scorecards does not recognize the symbolic link to UPSTREAM_SECURITY.md.
When merging into main then all Actions fire up, including the Semantic Release action. That then creates a new bump: commit and pushes that commit to main — which then fires up all Actions again.
Take a look at these Actions triggered by commit db56423:
First, commit db56423 triggers the CodeQL, Scorecard, and Check & Release actions, the latter pushing commit 174485c which in turn triggers these three Actions again.
I think we could prevent this from happening by adding [skip actions] (or some such, see docs) to the release commit:
python-package-template/pyproject.toml
Line 161 in 174485c
There’s been much discussion around changing the branch name master to main (e.g. here) and Github makes that fairly easy. Shall we?
We currently use a setup.py file to store package metadata and installation information. However, as the pip documentation mentions:
Prior to the introduction of pyproject.toml-based builds (in PEP 517 and PEP 518), pip had only supported installing packages using setup.py files that were built using setuptools. The interface documented here is retained currently solely for legacy purposes, until the migration to pyproject.toml-based builds can be completed.
And from issue slsa-framework/slsa-github-generator#55:
I think it's really our only option. We can do some things to guess the build backend that needs to be present, but it's not guaranteed to be correct, or capture all bulid-time dependencies. Instead, pyproject.toml is the standardized way to do this. I think it would be reasonable to say we only support building projects that specify pyproject.toml.
Let’s move on then, and move to pyproject.toml. For inspiration, @hynek has moved the structlog package to pyproject.toml (and uses Flit instead of Setuptools).
And while we’re at it:
flake8 does not (yet?) support pyproject.toml (see also issue PyCQA/flake8#234).The pull-request.yaml Action may not need to trigger the code checks and tests:
python-package-template/.github/workflows/pull-request.yaml
Lines 57 to 61 in f41b0e6
if the PR is in “draft” mode — the event payload has a boolean "draft":
build:
needs: conventional-commits
if: ${{ !github.event.pull_request.draft }}that we should be able to check. A draft PR by definition is incomplete and may or may not pass checks and tests…
Furthermore, I am tempted to change this
python-package-template/.github/workflows/pull-request.yaml
Lines 8 to 11 in f41b0e6
to
pull_request:
branches:
- *to target all PRs regardless of their base branch (i.e. PRs that target other PRs).
We also don’t need to run checks and tests if the PR body discussion has had an entry but there was no code change. In that case, maybe only run cz (because the PR title was changed), for example:
build:
needs: conventional-commits
if: ${{ github.event.action !== 'edited' }}Skipping the build job, however, means that no artifacts are produced by that particular Action run, which is probably acceptable.
Based on #259 (comment) (and #259 (comment)), and the follow-up conversation in #259 (comment).
For details, see #259 (comment).
The pre-commit-config file doesn't specify the configuration file(pylintrc) for pylint, so the pylint hook is running with its default settings.
This introduces a discrepancy between running pylint from pre-commit and github workflows.
The pre-commit-config for the pylint hook should be defined as:
- repo: local
hooks:
- id: pylint
name: Check lint
entry: pylint
language: python
files: ^src/package/|^tests/|setup.py
args: [--rcfile=pylintrc]
I came across a linter for GitHub Actions. It would be good to add it both as a pre-commit hook and as a CI check. I couldn't find an existing pre-commit hook for it and might need to create a local hook.
We currently use these credentials
python-package-template/.github/workflows/build.yaml
Lines 21 to 22 in c754175
to create and push a bump commit:
python-package-template/.github/workflows/build.yaml
Lines 76 to 78 in c754175
Which yields this commit:
commit c7541754294c634cd807068ffaf37bd0279cbb52 (HEAD -> main, tag: v2.2.0, origin/main, origin/HEAD)
Author: github-actions <[email protected]>
Date: Sun Jul 31 03:47:56 2022 +0000
bump: release 2.1.0 → 2.2.0
and Github then doesn’t associate a user with it:
I wasn’t able to find a definite suggestion in the Github documentation, but it looks like actions-user is available and used by other frameworks. It’s also the same user that python-semantic-release Action used (still does) before we replaced it with tailored code:
@behnazh perhaps we should use that user name instead, considering this repo isn’t part of an org which can have a dedicated devops account? Related conversation is python-semantic-release/python-semantic-release#473 (comment)
Our Makefile uses a .upgraded file to indicate when/if the venv has been upgraded:
python-package-template/Makefile
Lines 56 to 60 in 66347c6
I think the file should live in ${VIRTUAL_ENV}/.upgraded instead of the repo’s root, because it’s concerned with the venv only and removing the venv folder manually wouldn’t leave behind that now-stale file.
It would be nice to add Scorecard analysis to this repo as a GitHub Actions workflow to compute the security score. Scorecard runs various simple checks, e.g., whether Branch-Protection and Security-Policy exist in the repo, and computes a score of 0-1.
Here is the result that I get by locally running Scorecard:
RESULTS
-------
Finished [Binary-Artifacts]
Finished [Maintained]
Finished [Packaging]
Finished [CI-Tests]
Finished [Pinned-Dependencies]
Finished [Signed-Releases]
Finished [Vulnerabilities]
Finished [Branch-Protection]
Finished [Contributors]
Finished [Fuzzing]
Finished [Token-Permissions]
Finished [Security-Policy]
Finished [CII-Best-Practices]
Finished [Code-Review]
Finished [Dependency-Update-Tool]
Finished [SAST]
Aggregate score: 4.5 / 10
Check scores:
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| SCORE | NAME | REASON | DOCUMENTATION/REMEDIATION |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Binary-Artifacts | no binaries found in the repo | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#binary-artifacts |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 1 / 10 | Branch-Protection | branch protection is not | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#branch-protection |
| | | maximal on development and all | |
| | | release branches | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | CI-Tests | 14 out of 14 merged PRs | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#ci-tests |
| | | checked by a CI test -- score | |
| | | normalized to 10 | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 0 / 10 | CII-Best-Practices | no badge found | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#cii-best-practices |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 9 / 10 | Code-Review | GitHub code reviews found for | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#code-review |
| | | 13 commits out of the last 14 | |
| | | -- score normalized to 9 | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 0 / 10 | Contributors | 0 different companies found -- | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#contributors |
| | | score normalized to 0 | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Dependency-Update-Tool | update tool detected | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#dependency-update-tool |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 0 / 10 | Fuzzing | project is not fuzzed in | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#fuzzing |
| | | OSS-Fuzz | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 6 / 10 | Maintained | 8 commit(s) found in the last | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#maintained |
| | | 90 days -- score normalized to | |
| | | 6 | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| ? | Packaging | no published package detected | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#packaging |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 5 / 10 | Pinned-Dependencies | dependency not pinned by hash | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#pinned-dependencies |
| | | detected -- score normalized | |
| | | to 5 | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 0 / 10 | SAST | SAST tool is not run on all | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#sast |
| | | commits -- score normalized to | |
| | | 0 | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 0 / 10 | Security-Policy | security policy file not | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#security-policy |
| | | detected | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 0 / 10 | Signed-Releases | 0 out of 2 artifacts are | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#signed-releases |
| | | signed -- score normalized to | |
| | | 0 | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 0 / 10 | Token-Permissions | non read-only tokens detected | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#token-permissions |
| | | in GitHub workflows | |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Vulnerabilities | no vulnerabilities detected | https://github.com/ossf/scorecard/blob/54f1429eaa39592e61201497b108176aa2e545cc/docs/checks.md#vulnerabilities |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
Tracking issue for:
This use of date in this Makefile recipe:
python-package-template/Makefile
Line 107 in f41b0e6
expects a GNU Coreutils date in order to understand the --rfc-3339 command line option:
> date --rfc-3339=seconds
2022-10-04 20:47:50+10:00
However, for example out-of-the-box macOS ships with BSD date which does not understand that option:
> /bin/date --rfc-3339=seconds
/bin/date: illegal option -- -
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
In order to be more portable, we should probably change the above date invocation to
> date "+%Y-%m-%d %H:%M:%S %z"
2022-10-04 21:52:28 +1000
which works also works for the BSD version:
> /bin/date "+%Y-%m-%d %H:%M:%S %z"
2022-10-04 21:53:26 +1000
So, the Makefile goal should then be:
upgrade-quiet:
echo "Automatically generated by Python Package Makefile on `date '+%Y-%m-%d %H:%M:%S %z'`." > .venv/upgraded-onTracking issue for:
It would be nice to get the OpenSSF Best Practices badge. We need to tick the boxes listed on this page.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.