I've got an idea to fill the void of the non-existent PEP 517 build requirements provisioning. The problem is that
currently there's no first-class citizen support for reproducible builds in the PEP 517 world. People usually set
lower bounds on their build backend of choice and that's about it. Even if some will set exact pins in their
pyproject.toml, it's not enough because those entries may contain unpinned (transitive) dependencies. One way to
do this with python -m build is to set PIP_CONSTRAINTS environment variable (I haven't actually tested this yet
but I expect it to work).
That workaround is suboptimal and leaves the users with no answer on how to manage the invocations and the
| #!/bin/sh | |
| # Copyright (C) 2020 Michel Stam <michel@reverze.net> | |
| # Copyright (C) 2021 Hung-I Wang <whygowe@gmail.com> | |
| # | |
| # The script is adatped from: | |
| # https://github.com/ndilieto/uacme/blob/5edec0eea1bcf6f454ec1787297c2408c2f2e97a/nsupdate.sh | |
| # | |
| # Licensed under the the GNU General Public License <http://www.gnu.org/licenses/>. | |
| # The script is meant to be used as a hook script of uacme to update TXT records for acme challenges. |
It's come to my attention that some people have been spamming issue trackers with a link to this gist. While it's a good idea to inform people of the situation in principle, please do not do this. By all means spread the word in the communities that you are a part of, after verifying that they are not aware yet, but unsolicited spam is not helpful. It will just frustrate people.
A number of things have happened since the last update.
Here is the best setup (I think so :D) for K-series Keychron keyboards on Linux.
Note: many newer Keychron keyboards use QMK as firmware and most tips here do not apply to them. Maybe the ones related to Bluetooth can be useful, but everything related to Apple's keyboard module (hid_apple) on Linux, won't work. As far as I know, all QMK-based boards use the hid_generic module instead. Examples of QMK-based boards are: Q, Q-Pro, V, K-Pro, etc.
Most of these commands have been tested on Ubuntu 20.04 and should also work on most Debian-based distributions. If a command happens not to work for you, take a look in the comment section.
Older Keychron keyboards (those not based on QMK) use the hid_apple driver on Linux, even in the Windows/Android mode, both in Bluetooth and Wired modes.
The user experience of Python on a minimal Debian or Ubuntu installation is bad. Core features like virtual environments, pip bootstrapping, and the ssl module are either missing or do not work like designed and documented. Some Python core developers including me are worried and consider Debian/Ubuntu's packaging harmful for Python's reputation and branding. Users don't get what they expect.
The problems can be easily reproduced with official Debian and Ubuntu containers in Docker or Podman. Debian Stable (Debian 10 Buster) comes with Python 3.7.3. Ubuntu Focal (20.04 LTS) has Python 3.8.5.
| `git pull origin [main_branch_name]` | |
| `git checkout [merge_branch_name]` | |
| `git pull origin [main_branch_name] --rebase` | |
| `git push -f origin [merge_branch_name]` |
I’m thrilled to finally present attrs 20.1.0 with the following changes:
JUST KIDDING!
This release is HUGE and I'm stoked we can finally get it to you! It’s the result of more than a year of development and not only does it come with many great features that users desired for a long time, it also lays the foundation for the future evolution of this package.
https://github.com/potherca-blog/StackOverflow/blob/master/question.13808020.include-an-svg-hosted-on-github-in-markdown/readme.md
The purpose of raw.github.com is to allow users to view the contents of a file, so for text based files (SVG, JS, CSS, etc) this means you get the wrong headers and things break in the browser.
| # I've been trying to reconcile Python's concept of variables as references to values instead of | |
| # the values themselves with type annotations. I think I've hit upon some ideas. Unfortunately, | |
| # they aren't all compatible with Python's current type annotation syntax. | |
| # | |
| # Background: References vs values | |
| # ================================ | |
| # | |
| # In C, you might write some code like this:: | |
| # | |
| # #include<stdio.h> |