Add --profile argument to underlying aws s3 command using pulumi stack config

Hello!

Vote on this issue by adding a 👍 reaction
If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

When running pulumi up using pulumi_synced_folder.S3BucketFolder and aws configure sso, the underlying command is not able to run, could we have the stack configuration aws:profile added on to the end of the aws s3 command such as
aws s3 sync "./builds/server/files" "s3://server-dev2/pulumi/" --acl "private" --region "eu-west-1" --delete --only-show-error --profile aws-profile-name
Affected area/feature

This impacted me on nodjs, when I use SSO setup(the only one that has beein impacted by it). It´s a part of the cloudfront distribution template, so quite important.
// Use a synced folder to manage the files of the website.
const bucketFolder = new synced_folder.S3BucketFolder("bucket-folder", {
    path: path,
    bucketName: bucket.bucket,
    acl: "public-read",
}, { dependsOn: [ownershipControls, publicAccessBlock] });

➜  projecta git:(main) ✗ pulumi up                                                                                <aws:foundations-dev-FullAccess>
Enter your passphrase to unlock config/secrets
    (set PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE to remember):
Enter your passphrase to unlock config/secrets
Previewing update (foundations-dev):
     Type                                   Name                           Plan       Info
 +   pulumi:pulumi:Stack                    publishercopy-foundations-dev  create     2 errors
 +   ├─ aws:s3:Bucket                       bucket                         create
 +   ├─ aws:s3:BucketOwnershipControls      ownership-controls             create
 +   ├─ aws:s3:BucketPublicAccessBlock      public-access-block            create
 +   ├─ aws:cloudfront:Distribution         cdn                            create
 +   ├─ synced-folder:index:S3BucketFolder  bucket-folder                  create
     └─ aws:s3:BucketObject                 error.html                                1 error

Diagnostics:
  aws:s3:BucketObject (error.html):
    error: unable to validate AWS credentials.
    Details: loading configuration: profile "foundations-dev-FullAccess" is configured to use SSO but is missing required configuration: sso_region, sso_start_url

    Make sure you have:

     	 • Set your AWS region, e.g. `pulumi config set aws:region us-west-2`
     	 • Configured your AWS credentials as per https://pulumi.io/install/aws.html
     	 You can also set these via cli using `aws configure`.

  pulumi:pulumi:Stack (publishercopy-foundations-dev):
    error: Error: invocation of aws:index/getRegion:getRegion returned an error: unable to validate AWS credentials.
    Details: loading configuration: profile "foundations-dev-FullAccess" is configured to use SSO but is missing required configuration: sso_region, sso_start_url

    Make sure you have:

     	 • Set your AWS region, e.g. `pulumi config set aws:region us-west-2`
     	 • Configured your AWS credentials as per https://pulumi.io/install/aws.html
     	 You can also set these via cli using `aws configure`.

        at Object.callback (/snapshot/pulumi-resource-synced-folder/node_modules/@pulumi/pulumi/runtime/invoke.js:161:33)
        at Object.onReceiveStatus (/snapshot/pulumi-resource-synced-folder/node_modules/@grpc/grpc-js/src/client.ts:338:26)
        at Object.onReceiveStatus (/snapshot/pulumi-resource-synced-folder/node_modules/@grpc/grpc-js/src/client-interceptors.ts:426:34)
        at Object.onReceiveStatus (/snapshot/pulumi-resource-synced-folder/node_modules/@grpc/grpc-js/src/client-interceptors.ts:389:48)
        at /snapshot/pulumi-resource-synced-folder/node_modules/@grpc/grpc-js/src/call-stream.ts:276:24
        at processTicksAndRejections (node:internal/process/task_queues:78:11)
    error: Error: failed to register new resource bucket-folder [synced-folder:index:S3BucketFolder]: 2 UNKNOWN: invocation of aws:index/getRegion:getRegion returned an error: unable to validate AWS credentials.
    Details: loading configuration: profile "foundations-dev-FullAccess" is configured to use SSO but is missing required configuration: sso_region, sso_start_url

    Make sure you have:

     	 • Set your AWS region, e.g. `pulumi config set aws:region us-west-2`
     	 • Configured your AWS credentials as per https://pulumi.io/install/aws.html
     	 You can also set these via cli using `aws configure`.

        at Object.registerResource (/Users/thomas.dahll@schibsted.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/@pulumi/runtime/resource.ts:439:27)
        at new Resource (/Users/thomas.dahll@schibsted.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/@pulumi/resource.ts:507:13)
        at new ComponentResource (/Users/thomas.dahll@schibsted.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/@pulumi/resource.ts:1011:9)
        at new S3BucketFolder (/Users/thomas.dahll@schibsted.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/@pulumi/s3bucketFolder.ts:50:9)
        at Object.<anonymous> (/Users/thomas.dahll@schibsted.com/work/pulumi/pulumi-foundations/publishercopy/index.ts:34:22)
        at Module._compile (node:internal/modules/cjs/loader:1108:14)
        at Module.m._compile (/Users/thomas.dahll@schibsted.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/ts-node/src/index.ts:439:23)
        at Module._extensions..js (node:internal/modules/cjs/loader:1137:10)
        at Object.require.extensions.<computed> [as .ts] (/Users/thomas.dahll@schibsted.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/ts-node/src/index.ts:442:12)
        at Module.load (node:internal/modules/cjs/loader:988:32)

Outputs:
    cdnHostname   : output<string>
    cdnURL        : output<string>
    originHostname: output<string>
    originURL     : output<string>

    ```

This impacted me on nodjs, when I use SSO setup(the only one that has beein impacted by it). It´s a part of the cloudfront distribution template, so quite important.
// Use a synced folder to manage the files of the website.
const bucketFolder = new synced_folder.S3BucketFolder("bucket-folder", {
    path: path,
    bucketName: bucket.bucket,
    acl: "public-read",
}, { dependsOn: [ownershipControls, publicAccessBlock] });

➜  projecta git:(main) ✗ pulumi up                                                                                <aws:foundations-dev-FullAccess>
Enter your passphrase to unlock config/secrets
    (set PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE to remember):
Enter your passphrase to unlock config/secrets
Previewing update (foundations-dev):
     Type                                   Name                           Plan       Info
 +   pulumi:pulumi:Stack                    publishercopy-foundations-dev  create     2 errors
 +   ├─ aws:s3:Bucket                       bucket                         create
 +   ├─ aws:s3:BucketOwnershipControls      ownership-controls             create
 +   ├─ aws:s3:BucketPublicAccessBlock      public-access-block            create
 +   ├─ aws:cloudfront:Distribution         cdn                            create
 +   ├─ synced-folder:index:S3BucketFolder  bucket-folder                  create
     └─ aws:s3:BucketObject                 error.html                                1 error

Diagnostics:
  aws:s3:BucketObject (error.html):
    error: unable to validate AWS credentials.
    Details: loading configuration: profile "foundations-dev-FullAccess" is configured to use SSO but is missing required configuration: sso_region, sso_start_url

    Make sure you have:

     	 • Set your AWS region, e.g. `pulumi config set aws:region us-west-2`
     	 • Configured your AWS credentials as per https://pulumi.io/install/aws.html
     	 You can also set these via cli using `aws configure`.

  pulumi:pulumi:Stack (publishercopy-foundations-dev):
    error: Error: invocation of aws:index/getRegion:getRegion returned an error: unable to validate AWS credentials.
    Details: loading configuration: profile "foundations-dev-FullAccess" is configured to use SSO but is missing required configuration: sso_region, sso_start_url

    Make sure you have:

     	 • Set your AWS region, e.g. `pulumi config set aws:region us-west-2`
     	 • Configured your AWS credentials as per https://pulumi.io/install/aws.html
     	 You can also set these via cli using `aws configure`.

        at Object.callback (/snapshot/pulumi-resource-synced-folder/node_modules/@pulumi/pulumi/runtime/invoke.js:161:33)
        at Object.onReceiveStatus (/snapshot/pulumi-resource-synced-folder/node_modules/@grpc/grpc-js/src/client.ts:338:26)
        at Object.onReceiveStatus (/snapshot/pulumi-resource-synced-folder/node_modules/@grpc/grpc-js/src/client-interceptors.ts:426:34)
        at Object.onReceiveStatus (/snapshot/pulumi-resource-synced-folder/node_modules/@grpc/grpc-js/src/client-interceptors.ts:389:48)
        at /snapshot/pulumi-resource-synced-folder/node_modules/@grpc/grpc-js/src/call-stream.ts:276:24
        at processTicksAndRejections (node:internal/process/task_queues:78:11)
    error: Error: failed to register new resource bucket-folder [synced-folder:index:S3BucketFolder]: 2 UNKNOWN: invocation of aws:index/getRegion:getRegion returned an error: unable to validate AWS credentials.
    Details: loading configuration: profile "foundations-dev-FullAccess" is configured to use SSO but is missing required configuration: sso_region, sso_start_url

    Make sure you have:

     	 • Set your AWS region, e.g. `pulumi config set aws:region us-west-2`
     	 • Configured your AWS credentials as per https://pulumi.io/install/aws.html
     	 You can also set these via cli using `aws configure`.

        at Object.registerResource (/Users/thomas@comp.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/@pulumi/runtime/resource.ts:439:27)
        at new Resource (/Users/thomas@comp.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/@pulumi/resource.ts:507:13)
        at new ComponentResource (/Users/thomas@comp.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/@pulumi/resource.ts:1011:9)
        at new S3BucketFolder (/Users/thomas@comp.com.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/@pulumi/s3bucketFolder.ts:50:9)
        at Object.<anonymous> (/Users/thomas@comp.com.com/work/pulumi/pulumi-foundations/publishercopy/index.ts:34:22)
        at Module._compile (node:internal/modules/cjs/loader:1108:14)
        at Module.m._compile (/Users/thomas@comp.com.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/ts-node/src/index.ts:439:23)
        at Module._extensions..js (node:internal/modules/cjs/loader:1137:10)
        at Object.require.extensions.<computed> [as .ts] (/Users/thomas@comp.com.com/work/pulumi/pulumi-foundations/publishercopy/node_modules/ts-node/src/index.ts:442:12)
        at Module.load (node:internal/modules/cjs/loader:988:32)

Outputs:
    cdnHostname   : output<string>
    cdnURL        : output<string>
    originHostname: output<string>
    originURL     : output<string>

    ```

Hello! I am also experiencing this issue.
Basically, following the Pulumi's AWS Static Website instruction doesn't work if you use aws configure sso and aws sso login to manage AWS credentials, which looks like a preferred way nowadays to avoid storing long-term credentials locally (e.g. see here).
The error output is exactly the same as for Dill-Dall above (except for project and profile names).

Have just found out that updating the version of @pulumi/synced-folder from 0.0.9 to 0.11.1 fixes the issue for me.
Made a pull request to update the template for AWS Static Website (TypeScript): https://github.com/pulumi/templates/pull/742


Update sbt to 1.5.0

Updates org.scala-sbt:sbt from 1.4.9 to 1.5.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-sbt", artifactId = "sbt" } ]

labels: library-update, semver-minor

https://github.com/scala/scala3.g8/commit/12e8b19957a7d375ee1e819ea3e57475ab854275


Add entry for my first Jekyll plugin jekyll-google_search_console_verification_file

Add a post for my first Jekyll plugin:
https://rubygems.org/gems/jekyll-google_search_console_verification_file

Thank you for merging!
@parkr @DirtyF is Netlify configured to automatically deploy pushes to the master branch in this git repo to
https://jekyll-directory.netlify.app/
?


update SQL Injection link

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
❌

Fixed issues
https://github.com/yiisoft/yii2/issues/19011

Thanks


Docs build

JIRA: HACBS-522

It looks like this: https://gist.github.com/simonbaird/8e0b9cc44e7dfec03b8efade89525569 .

Notes about this current revision:

Ditch the artifact and instead check in the generated docs file, but add a CI check to make it less annoying to keep it updated.
It's also visble in pages, here is a preview: https://simonbaird.github.io/ec-policies/

I'm putting more work on top of this, which would make the PRs hard to manage. Let's merge.


Add GMP Linker Support

I am attempting to use the multi-party-ecdsa library which uses GMP in my Rust lambda function. GMP is a precision arithmetic library which is commonly used in cryptography research, especially via Rust, so its support would be widely useful for the systems, security, and applied cryptography communities.
Running cargo lambda build causes the following error:
error: linking with /Users/daryakaviani/Library/Caches/cargo-zigbuild/0.11.1/zigcc-x86_64-unknown-linux-gnu.sh
...
ld.lld: error: unable to find library -lgmp

This is specific to cargo-lambda's usage of the zigbuild linker because cargo build works successfully when gmp is installed. Also, cargo zigbuild works, so it could be the specific way cargo-lambda handles environment variables in relation to the zigbuild linker. This error is exclusively introduced when I import multi-party-ecdsa in src/main.rs. To confirm that this is a machine-agnostic issue, I tried it on x86-64 Ubuntu, x86-64 Amazon Linux, x86-64 MacOS, and ARM M1 MacOS and received the same results. I attempted a workaround on Linux by disabling the zigbuild linker:
cargo lambda build --disable-zig-linker

cargo lambda deploy \
  --iam-role arn:aws:iam::XXXXXXXXXXXX:role/rust_lambda_test \
  func_name

cargo lambda invoke --remote \
--data-ascii '{"params": "some params"}' \
--output-format json \
func_name

This successfully compiled my artifacts and deployed the function, but invocation caused:
Error: Runtime.ExitError

  × RequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Error: Runtime exited with error: exit status 1

Is it possible for cargo-zigbuild or cargo-lambda to be updated for GMP support? If there is an existent workaround, please let me know and feel free to move this to Discussions!
@calavera @messense

other cargo lambda subcommands will work

@calavera This approach did not work for me. Using cargo zigbuild before deploying (even for a simple function that works with cargo lambda build) causes issues. Am I going wrong somewhere?

Ran cargo zigbuild --release. This generated an executable with name YOUR_PACKAGE_NAME in the release folder.
I copied the executable into the folder target/lambda/YOUR_PACKAGE_NAME and renamed the executable bootstrap.
Deployed successfully with cargo deploy.
Invokation causes the following error:

Response
{
  "errorType": "Runtime.ExitError",
  "errorMessage": "RequestId: 744d2237-3c02-4240-8405-aef8e90bf9c0 Error: Runtime exited with error: exit status 1"
}

Function Logs
/var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /var/task/bootstrap)
/var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /var/task/bootstrap)
/var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /var/task/bootstrap)
/var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /var/task/bootstrap)
/var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /var/task/bootstrap)
/var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /var/task/bootstrap)
/var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /var/task/bootstrap)
/var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /var/task/bootstrap)

@calavera Thanks for the update. Unfortunately, this did not seem to fix the problem. cargo zigbuild still works, but after updating to 0.13.0, cargo lambda build still results in:
error: linking with `/home/ubuntu/.cache/cargo-zigbuild/0.14.1/zigcc-x86_64-unknown-linux-gnu.sh` failed: exit status: 1
  |
...
  = note: warning: unsupported linker arg: -znoexecstack
          warning: unsupported linker arg: -zrelro
          warning: unsupported linker arg: -znow
          ld.lld: error: unable to find library -lgmp

Are there linking nuances in relation to the zigbuild?

Are you sure you're not using docker or some other host to run zigbuild

@calavera Yep, I am running cargo zigbuild in the same directory as cargo lambda build. To recreate the issue, you can start from your basic lambda example.
In main.rs, import:
use multi_party_ecdsa::protocols::multi_party_ecdsa::gg_2020::state_machine::keygen::Keygen;
use round_based::{StateMachine};

To Cargo.toml, add to dependencies:
round-based = { version = "0.1.4", features = ["dev"] }
multi-party-ecdsa = { version = "0.8.1", git = "https://github.com/ZenGo-X/multi-party-ecdsa.git" }

You should see that in both MacOS and Linux, cargo zigbuild works but cargo lambda build does not work.

Does settings RUSTFLAGS='-L my/lib/directory' env var work?

IMO zig won't help with the glibc version issue when linking external dylibs since the GMP shared library might require a higher glibc version.


[cdc] fixed unable to remove options

Purpose

When user remove table option and restart the paimon action task, the option that should be removed still exists in the schema

Tests

API and Format

Documentation

+1

+1


allow splitting /home to a seperate drive when installing

Currently, when installing you select a single drive to install to. I'm interested in putting my /home as a partition on a different drive(taking up whole drive is fine) instead of a subvolume. This might be fringe enough to not support, but it doesn't seem like it should be too difficult. /home doesn't need to be upgraded so it doesn't need to be touched after install.

Thanks for the report. I don't think I understand what you mean, though. Do you mean having multiple installation directories set at the same time?

Ah, now I get it. Not sure why I didn't understand in the first place. Thanks for clarifying.
I guess support for this could be done, but I'm not sure if it would provide us with a significant benefit. The root partition is so small that it doesn't really take away enough space to require a second disk. Even the smallest SSD would have a ton of free space left.

It is less important for saving space with the other partitions being small, but could still benefit from enabling slightly faster bootup using a ssd that won't store as many games as a larger mechanical drive.
As I said, it could be too niche a case, but is something I wanted to do to a machine I knew I could with other distro installers.

After thinking about it some more, It'd be more useful to consider RAID/LVM/etc before this. I'm closing this since this method seems of little benefit.


Build failed for macOS Big Sur

/var/folders/cp/358g81hn4s758wq49dgwg53r0000gn/T/_tmp_dangerfile.swift:1:8: error: module compiled with Swift 5.2.4 cannot be imported by the Swift 5.3.1 compiler: /usr/local/lib/danger/Danger.swiftmodule
import Danger
       ^

ERROR: Dangerfile eval failed at Dangerfile.swift
ERROR: Could not get the results JSON file at /var/folders/cp/358g81hn4s758wq49dgwg53r0000gn/T/danger-response.json

MacOS 11.0.1
Xcode 12.2

module compiled with Swift 5.2.4 cannot be imported by the Swift 5.3.1 compiler

Could you help please? Thanks

I would need some more informations:
How did you install Danger?
Are you caching something Danger related?
Because from what I see looks that the Danger library was builded with a different Xcode

I'm installing with brew, like the documentation said.
brew install danger/tap/danger-swift
But I think it's something related with macOS 11.
When I run brew doctor, I receive the warning:
➜ Danger-iOS ricardo-hochman-patch-1 brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: A newer Command Line Tools release is available.
Update them from Software Update in System Preferences or run:
  softwareupdate --all --install --force

If that doesn't show you an update run:
  sudo rm -rf /Library/Developer/CommandLineTools
  sudo xcode-select --install

Alternatively, manually download them from:
  https://developer.apple.com/download/more/.

Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  gettext

Warning: You are using macOS 11.0.
We do not provide support for this released but not yet supported version.
You will encounter build failures with some formulae.
Please create pull requests instead of asking for help on Homebrew's GitHub,
Discourse, Twitter or any other official channels. You are responsible for
resolving any issues you experience while you are running this
released but not yet supported version.

Warning: Your CLT does not support macOS 11.0.
It is either outdated or was modified.
Please update your CLT or delete it if no updates are available.
➜ Danger-iOS ricardo-hochman-patch-1 softwareupdate --all --install --force
Software Update Tool

Finding available software
No updates are available.

Try to run the suggested command
sudo xcode-select --install
and then sudo xcode-select -p does it prints the path to the new xcode?

I think there was a problema with my CLT, I just reinstalled it and danger again and it's working :) sorry for the inconvenience!

Cool, I'll close this then :)


Update README.md

replaced old docker hub name, the old link should be also replaced in the repository description! :)

Thank you :)


Usage behing http proxy

Would it be possible to use spotify-connect behind a http-proxy? (squid)
Just using the enviroment variables for example.
i tried to redirect everything via iptables, unfortunately due ssl it's not working.

I think spotify itself uses a non-http protocol, so you might need to use a socks proxy.
You can try using something like tsocks or proxychains to force it to go through the proxy
http://www.binarytides.com/proxify-applications-with-tsocks-and-proxychains-on-ubuntu/


Fixed incorrectly named json keys to match Initial State's API Spec

Merge pull request - fix to json keys name


fix: __COMMIT_HASH and __APP_VERSION refactor trailing underscores

These moved to vite.config.ts with trailing underscores, which was crashing useSettings hook and DebugTab.tsx. Removal of these underscores fixes both #851 and #852 for me, please review.

Dupe of #853 which just merged, disregard.


fix(parameters): Respect POWERTOOLS_PARAMETERS_SSM_DECRYPT environment variable when getting multiple parameters.

When getting multiple ssm parameters by path, the POWERTOOLS_PARAMETERS_SSM_DECRYPT environment variable should be respected as to whether to automatically decrypt the values, as is with the single get.

Issue number: 3240
Summary
Check the value of the POWERTOOLS_PARAMETERS_SSM_DECRYPT and respect that when deciding
whether to decrypt multiple parameters that were loaded.
Changes

The get_multiple method of the ssm provider will check the value of the environment variable, when deciding
whether to decrypt. The default remains false for the case where none exists, or no explicit parameter is passed.

User experience

The user can get multiple parameters, decrypted, by setting the environment variable.

Checklist
If your change doesn't seem to apply, please leave them unchecked.

[x] Meet tenets criteria
[x] I have performed a self-review of this change
[x] Changes have been tested
[ ] Changes are documented
[x] PR title follows conventional commit semantics

Is this a breaking change?
RFC issue number:
Checklist:

[ ] Migration process documented
[ ] Implement warnings (if it can live side by side)

Acknowledgment
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (115e666) 95.96% compared to head (9b17331) 95.92%.
Report is 2 commits behind head on develop.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #3241      +/-   ##
===========================================
- Coverage    95.96%   95.92%   -0.05%
===========================================
  Files          195      195
  Lines         8387     8386       -1
  Branches      1563      619     -944
===========================================
- Hits          8049     8044       -5
- Misses         276      278       +2
- Partials        62       64       +2

Files
Coverage Δ

aws_lambda_powertools/utilities/parameters/ssm.py
97.60% <100.00%> (+0.01%)
:arrow_up:

... and 3 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

LGTM!

Thank you!


Inspect lemmas in tests/specs/lemmas.k and tests/specs/infinite-gas.k for duplicates and pull out tests/specs/int-simplification.k

There do seem to be some duplicated LHSs, but the side conditions are different. For example:
// INFINITE-GAS
    rule S1 +Int (S2 +Int I3) => (S1 +Int S2) +Int I3 [symbolic(S1, S2), simplification]
// INFINITE-GAS-JAVA
    rule S1 +Int (S2 +Int I3) => (S1 +Int S2) +Int I3 requires (notBool #isConcrete(S1)) andBool (notBool #isConcrete(S2)) [simplification]
// LEMMAS-JAVA
    rule I1 +Int (I2 +Int C) => (I1 +Int I2) +Int C when #isConcrete(I1) andBool #isConcrete(I2) andBool notBool #isConcrete(C) [simplification]

Assuming when is similar to requires, then the first two seem very similar but the third is inverted. There are a few more similar rules in each corresponding module as well. However the -HASKELL modules don't have similar rules of this form.

INFINITE-GAS-COMMON has these rules which seem out-of-place:
    rule (notBool (A andBool B)) andBool A => (notBool B) andBool A                      [simplification]
    rule #if B #then C +Int C1 #else C +Int C2 #fi => C +Int #if B #then C1 #else C2 #fi [simplification]

    rule I -Int I => 0              [simplification]
    rule (I1 -Int I2) +Int I2 => I1 [simplification]

    rule X -Int Y +Int Z <=Int A => false requires A <Int X -Int Y andBool 0 <=Int Z [simplification]

Blocked on #1032

Wait for #1032 to merge before revisiting


[FEATURE] Update the Discord logo to the latest version

Is your feature request related to a problem? Please describe.
The Discord logo at the footer is the old logo. It should be the latest one.
Describe the solution you'd like
Update the Discord logo to the latest version at the footer.
Describe alternatives you've considered
None.

This has been open for months. If new version of website has already fixed it, link to relevant issue and close


[share] plugin: Update gradle version of example for Android

Description
[share] plugin: Update gradle version of example for Android
Fixes [TAG] Warnings and errors caused as generated on Android Studio build terminal while buidling.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[ ] All existing and new tests are passing.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] The analyzer (flutter analyze) does not report any problems on my PR.
[ ] I read and followed the Flutter Style Guide.
[ ] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[ ] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[ ] I updated CHANGELOG.md to add a description of the change.
[x] I signed the CLA.
[ ] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

@blasten done, have a look please.


Show representative point tooltip on hover

I would prefer on click for performance reasons, thoughts @viviandien ?

That seems reasonable to me. I believe that’s how ArcGIS handles it as well. Makes sense for a large number of points


feat z-index

Describe pull-request
Clean up z indexes
Charlotte together with Johnny have come up with a z-index table with new values associated with each component. Let's try to implement that in our components and see if all behaves as expected, or if we need to make changes to this table.
Test that both in the sandbox and in the angular demo.
https://www.figma.com/file/P9o0JuuAcdYY52lUAz3nMK/Elevation-principles?node-id=2:2
Technical solution idea: https://www.smashingmagazine.com/2014/06/sassy-z-index-management-for-complex-layouts/
Solving issue
Fixes: AB#2308
How to test
Checkout the file changes, and please do a quick smoke test in the deploy preview below 🙏

@theJohnnyMe @nathalielindqvist @EmelieLitwin since Alex is gone until January I think we should go ahead and merge this one 😄


Add support for the Zenoh Client's usage of the micro URI

Per spec, the Zenoh client uses the micro URI serialization for UUri. However, it has support for one extra ** UUri mode that requires the ability to serialize only the UAuthority.
This change splits out the UAuthority serialization into its own static method, which can be used both when serializing full UUris and when generating Zenoh keys for the ** mode.
Note: This PR is dependent on #73 and cannot be merged until that PR is complete.

This PR can be reviewed now. However, only the last commit (8d1fac3) should be reviewed. All commits before that are from #73. Once #73 is merged, I'll take this out of draft state so it's clear that it is ready to go.

... surely represents a large amount of work.

This PR can be reviewed now. However, only the last commit (8d1fac3) should be reviewed. All commits before that are from #73. Once #73 is merged, I'll take this out of draft state so it's clear that it is ready to go.


caching queryset & cleanup cloning and initialization

Changes

Make QuerySet nearly keyword only and deprecate keywords not matching function names.
Clone QuerySet via __init__.
Make select_related variadic and deprecate former call taking a Sequence.
Improved QuerySet caching.

Nice one


Rest Framework Tests: Improve speed and repeatability

ViewSets: Support get_queryset function for more flexible queryset manipulation
Authorization helpers: Specify order by id for most queries. For queries that already had a specified ordering, it was left alone if the field was unique on the model, such as Products. Otherwise, the ordering was changed to id
Viewsets: enagegement checklist serializer was not used, so removed
Tests: Accomodate the enforced ordering
Tests: Reduce logs for CICD tests to speed up testing overall by eliminating write operations
Tests: Enable FailFast mode ("Tells Django to stop running the test suite after first failed test.")
Tests: Enable shuffle tests to identify areas of tests that are dependent on each other
Tests: Enable parallel tests to drastically reduce testing time

In local testing, I went from ~240 seconds to ~45 seconds

[sc-6766]

@kiblik I was not planning on figuring out the shuffle issue quite yet, but addressing inconsistent ordering in API responses largely corrected those problems. I did not intended to steal your thunder, and I hope you do not feel that way 🙏🏼
I also did not plan on the parallel flag either, but I ran it just for kicks and encountered a different error this time around. It keyed me into to looking at how files were passed as class variables. Files, stack traces, and a few other things are not able to be serialized. Anyway, I thought you'd like to know what the underlying issue was 😄

@kiblik I was not planning on figuring out the shuffle issue quite yet, but addressing inconsistent ordering in API responses largely corrected those problems. I did not intended to steal your thunder, and I hope you do not feel that way 🙏🏼
I also did not plan on the parallel flag either, but I ran it just for kicks and encountered a different error this time around. It keyed me into to looking at how files were passed as class variables. Files, stack traces, and a few other things are not able to be serialized. Anyway, I thought you'd like to know what the underlying issue was 😄

No hard feelings 😄 I will be happy when it will be solved


Fixed insane cpu usage by adding a very small sleep at the end of the…

… loop.
This results in a very small input delay that is not recognizable.

Can we get this merged? I have a project using this, but it's killing user's batteries.

Great module, but the high CPU usage is kinda annoying. Please accept this commit and merge.
Thanks


Extension of ReplicatedSharedTensor to Binary,Prime order rings.

Description
Extended RST to binary, prime order ring_sizes ,as it is required for higher level functionalities of Falcon.
Affected Dependencies
List any dependencies that are required for this change.
How has this been tested?
Added tests for the same.
Checklist

[x] I have followed the Contribution Guidelines and Code of Conduct
[x] I have commented my code following the OpenMined Styleguide
[x] I have labeled this PR with the relevant Type labels
[x] My changes are covered by tests

@rasswanth-s are there any more changes required? We can merge this, right?


chore(deps): update typescript to 4.9.5

Which problem is this PR solving?

typedoc-plugin-resolve-crossmodule-references is now deprecated and typedoc >= 0.24.0 has the function built-in.
typedoc >= 0.24.0 requires typescript >= 4.6.0

Short description of the changes

Upgraded typescript to 4.9.5.
Fixed all conflict dependencies.
Fixed type errors.

** I tried upgrading to typescript@5 but it doesn't support node < 12 anymore so I used the last version ^4
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Existing Tests

Checklist:

[x] Followed the style guidelines of this project

Is there a difference in the generated d.ts files which requires consumers to use also a newer TS version?
If yes I would expect such a change is breaking.

Is there a difference in the generated d.ts files which requires consumers to use also a newer TS version?
If yes I would expect such a change is breaking.

I think it is safe of upgrading minor versions.

I think we should leave this PR open a bit to allow people to review it. I'll also review the generated files to ensure we're not missing anything.
There can be breaking changes in typescript minor versions as typescript does not follow semver.

Is there a difference in the generated d.ts files which requires consumers to use also a newer TS version?
If yes I would expect such a change is breaking.

Is there a difference in the generated d.ts files which requires consumers to use also a newer TS version?
If yes I would expect such a change is breaking.

I think it is safe upgrading minor versions.

Marc is definitely correct there are breaking changes in minor TS versions and breaking changes in the output. There are projects like https://github.com/sandersn/downlevel-dts which allow you to publish types compatible with old ts versions in parallel with modern types.
The 2 changes to the output relevant to us are:

Type modifiers on import names
Optional Variance Annotations for Type Parameters

Looking at marc's diff I don't see anywhere these are used in the output, but they could be at any point in the future. Right now if we try to use these features Typescript will simply fail to compile. If we upgrade our TS version and some PR uses either of these features in the future then we will be breaking users.
Ideally I would like to see at least one of the following if not both in order to accept this PR:

Use a project like downlevel-dts to publish old-ts-safe types alongside modern types
A test which compiles a project using the API with typescript 4.4

If we upgrade our TS version and some PR uses either of these features in the future then we will be breaking users.

Do we have such statement in the docs saying we support<EMAIL_ADDRESS>If not, I think doing such compatibility support is kind of redundant as it works for now and we don't promise to support<EMAIL_ADDRESS>in the future.
BTW, I think we should upgrade to ts@5 in the next major release.

If we upgrade our TS version and some PR uses either of these features in the future then we will be breaking users.

Do we have such statement in the docs saying we support<EMAIL_ADDRESS>If not, I think doing such compatibility support is kind of redundant as it works for now and we don't promise to support<EMAIL_ADDRESS>in the future.

We do this implicitly by adhering to semver.

BTW, I think we should upgrade to ts@5 in the next major release.

Yes, we discussed this a few times in the SIG meeting already, but we did not have an issue as of now. I created one and added it to the 2.0 milstone: #3955

API compatibility with different ts versions is hard in general. New ts versions may have better type checking which may result in broken builds. Also built in types in typescript may have impact.
Refs: #3636, #3660
Also minor changes in types only may cause breakage independent of the ts version. So keeping 100% compatibility with typescript in mind is quite hard, if only the pure JS API surface is taken it's by far easier.
We had several issues in the past that adding a private member in an exported class caused issues.
So maybe we have to even specify a fix ts version to ensure no breakage happens. But that would be quite bad.

@llc1123, there has been some movement on this issue:
We plan to update typescript to the most recent version with a 2.0 release of the SDK (#4083), as we've concluded this will be a breaking change.
We may also introduce a policy that will allow us to bump typescript more regularly without having to bump the major version, similar to what other projects do, though this is still up for debate (i'll link the issue here once it's available). Though with the currently proposed approach of one major release each year, we'll probably also be able to keep typescript reasonably up-to-date without this policy.

LGTM. I've been really busy recently and didn't have time to look at the updates. I'll be back in October and take care of the remaining issues.

There's currently a PR incoming from #3955 which will bump typescript to 5.2 (this is for the 2.0 release)
We'll not go with the route of allowing typescript bumps in minor versions, but we'll instead:

bump to the latest typescript version available on SDK 2.0 release
do regular major bumps to otel js (every one to two years) that'll allow us to keep everything reasonably up-to-date.

I'll close this PR in the meantime.


ConsoleTextTransform: Use ansi_up

Use ansi_up for converting ANSI color escape codes.
This will allow to render all colors in this notebook correctly.

LGTM, thanks for this! :ship:

What about shipping a release?

Good point. I am not confident enough to cut a release myself as I've been a bit disconnected from the project and got several things happening for the rest of the day.
/paging @rgbkrk @jdfreder

@lgeiger I've added you to the npm package for transformime-jupyter-transformers, though I'll make a minor release with this now (since this is a big change to dependencies).

$ git checkout master && git pull origin/master
$ npm version minor && git push && git push --tags && npm publish
...
+<EMAIL_ADDRESS>

Thanks for taking care of this.


Add test cases

Add some test cases to check basic tool functionality. If possible, enable test invocation via setup.py installer, e.g. python setup.py test.

Fixed: We've got >90% test coverage in experimental.


Remove moot version property from bower.json

Per bower/bower.json-spec@a325da3
Also their maintainer says they probably won't ever use it: http://stackoverflow.com/questions/24844901/bowers-bower-json-file-version-property

Thank you for the links!


RFE: generalize/simplify podman's handling of configuration options and files

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature
Description
First off, I should note I'm not familiar with the wealth of environments that podman is being run in, so I don't have a lot of domain specific knowledge, but I'll go out on a limb anyway.
I'm working on a network where user home directories are NFS mounted and shared across multiple heterogeneous hosts. Each host requires it's own set of configuration files to match local conditions, such as different storage drivers (e.g. vfs vs. overlay), different names for local storage directories, mount configurations, etc.
I've run into some difficulties mapping the existing set of configuration options (which I'm sure have a sound historical basis) onto this model.
There isn't currently a consistent and comprehensive interface to manage the configuration files, configuration options, or sets of configuration files. The existing approach seems geared towards a very particular environment.
For instance, --config is available to specify the location of libpod.conf, but there are no similar options for storage.conf, or mount.conf.  A subset of the configuration variables in storage.conf may be modified via the --root, --storage--driver, --storage-opt, and accompanying XDG_DATA_HOME, STORAGE_DRIVER and STORAGE_OPT environment variables.
The only means of choosing between different sets of configuration files is via the XDG_CONFIG_HOME environment variable, which is an awkward fit, as conceptually it indicates that all of the user's configuration is located there, when in fact it's being used to specify just the podman configuration. For example, in my environment, it's not possible for a user to simply set XDG_CONFIG_HOME on a per host basis without possibly breaking any number of other systems or programs.  Instead, to be safe, one must run
XDG_CONFIG_HOME=$PODMAN_CONFIG_HOME podman

There's a further complication that changing configuration values often leads to a conflict with what's in bolt_state.db, so I find myself constantly performing the following ritual
pkill podman
rm bolt_state.db
podman info

While there are undoubtedly good reasons why one would change some of the configuration options at run time, there's a fragility in there which means that effectively it doesn't work out that way.
I recognize that podman uses other commands under the hood, and it may be impossible to provide a uniform and comprehensive interface.  In that case, I think it'd better to recognize that upfront and deem that podman shouldn't single out particular options as it does now, but leave configuration to the configuration files. That may reduce flexibility, but I think it would make things more resilient.
I think the simplest approach is to have podman choose between sets of configuration files, using a search path that looks like
$PODMAN_CONFIG_HOME:$XDG_CONFIG_HOME/.config/containers:$HOME/.cconfig/containers

and leave it at that. (Edit: add a command line option to set PODMAN_CONFIG_HOME)
`If runtime modification is required, provide a uniform interface, e.g.
-D storage.driver="overlay" -D mounts./tmp/wprkdir=/tmp/workder

etc, and then update a copy of the current configuration files with the updated values and pass those along to the subsystems.  And somehow keep bolt_state.db updated.

Sorry that this got ignored. We're in the middle of a big rework of Podman as a whole, and this got caught in the cracks.
One piece of interesting news is that we've introduced a new configuration file, containers.conf, which unifies a lot of options and will eventually replace libpod.conf; unfortunately, it does not include storage or image configuration, as those are separate libraries. That's also why we have no flag to set configuration files for those two, though it should be doable to allow.
We are moving away from storing most configuration in the user's homedir (I think we still create a storage.conf though) which may alleviate some of your configuration swapping pain. It may be worth adding an alternative config location for rootless Podman, but it's hard to tell exactly where that should live, given that there aren't many places that survive reboot we can safely use outside of the user's home. I don't know that I want to involve environment variables in this more than the standard XDG_CONFIG_HOME and similar.

We have done this with the introduction of containers.conf


Migrate default theme from bootstrap2 to bootstrap3

@pydanny I can port it to Bootstrap3. Would you like that?

@vinitkumar if you can that would be really awesome! :+1:


Distinguish new txn hashes from old

Distinguish new transaction hashes from old by prepending a byte in the string representation (currently B, but opinions welcome). Don't expose the Base58Check functions in Transaction_hash, instead expose to_string and of_string, which use the Base58Check functions internally. The of_string function can raise, so there are try blocks where we had of_base58.
Transaction_hash.hash_signed_command_v1 uses this new representation by converting a V1 signed command to V2, then calling hash_signed_command. This is the same strategy we'll use for the database migration to convert hashes.

!ci-build-me

!ci-build-me

Wrong approach!


TimeLabel formatting

Just an idea from me, but not thoroughly tested with UI.
I think this approach looks much cleaner. Saw it on YouTube player.
Just, padding around these time labels (especially side ones) needs to be updated to track time labels' width changes.

Yes, I think I agree. However, since this change will affect everyone's UI, I opened an issue first to solicit feedback. (#25)

I haven't heard any other feedback from anyone. Seems like a good change to me. I'm merging. Thank you for your PR.


remove oauth2-server, change to @node-oauth/oauth2-server

@node-oauth/oauth2-server has been forked from oauthjs/node-oauth2-server and is a continuation due to the project appearing to be abandoned.
The original oauth2-server lacks updates and has some vulnerabilities. It's not safe to use now.
Here are some breaking changes between oauth2-server@3 and @node-oauth/oauth2-server@5.
For example, it removes callback support for OAuthServer and model implementation. So this should be a major version update.
For more details, please refer to https://github.com/node-oauth/node-oauth2-server/blob/master/CHANGELOG.md

@bangbang93 The new version has been released. Thank you for your help.  🎉


[stable/mariadb] Fix 'MARIADB_MASTER_PORT_NUMBER' in templates/slave-statefulset.yaml

What this PR does / why we need it:
The value of MARIADB_MASTER_PORT_NUMBER was incorrectly set in templates/slave-statefulset.yaml.
Currently this value is set to '3306'.
        - name: MARIADB_MASTER_PORT_NUMBER
          value: "3306"

If you change the service.port property in values.yaml to '13306', the port of service will be set to 13306.
$ k -n test get svc
NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                         AGE
helm-test-mariadb         ClusterIP      <IP_ADDRESS>    <none>          13306/TCP                       20h
helm-test-mariadb-slave   ClusterIP      <IP_ADDRESS>   <none>          13306/TCP                       20h

However, because the MARIADB_MASTER_PORT_NUMBER value in Slave is still '3306', replication fails.
Therefore, this value should be modified as follows:
        - name: MARIADB_MASTER_PORT_NUMBER
          value: "{{ .Values.service.port }}"

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

Thanks for your contribution!

/ok-to-test
/lgtm


Proposal: make Embark without dashboard less verbose

Overview
Embark spins up a nice dashboard view within the terminal by default. Some people however, prefer to start Embark without getting a dashboard, which is why we support a --nodashboard option as part of the run command.
The result is Embark doing its work and only outputting a log of whatever is going on.
While this is great to have, I believe we can improve the no-dashboard scenario a little bit, by making the output sent to stdout less verbose.
For example, instead of output sth. like:
registerAPICall get /embark-api/contracts/logs                                                                                [0/1796]
registerAPICall get /embark-api/contract/:contractName
registerAPICall post /embark-api/contract/:contractName/function
registerAPICall post /embark-api/contract/:contractName/deploy
registerAPICall get /embark-api/contracts
registerAPICall post /embark-api/contract/deploy
registerAPICall get /embark-api/blockchain/gas/oracle
registerAPICall ws /embark-api/blockchain/gas/oracle
registerAPICall post /embark-api/command
registerAPICall post /embark-api/authenticate
ready to watch file changes
Starting Blockchain node in another process
registerAPICall ws /embark-api/process-logs/blockchain
registerAPICall get /embark-api/process-logs/blockchain
IPFS node not found, attempting to start own node
adding get /embark-api/processes
adding ws /embark-api/process-logs/blockchain
adding get /embark-api/process-logs/blockchain
adding get /embark-api/blockchain/accounts
adding get /embark-api/blockchain/accounts/:address
adding get /embark-api/blockchain/blocks
adding get /embark-api/blockchain/blocks/:blockNumber
adding get /embark-api/blockchain/transactions
adding get /embark-api/blockchain/transactions/:hash
adding ws /embark-api/blockchain/blockHeader
adding get /embark-api/file
adding post /embark-api/files
adding delete /embark-api/file
adding get /embark-api/files
adding post /embark-api/contract/compile
adding get /embark-api/versions
adding ws /embark-api/contracts/logs
adding get /embark-api/contracts/logs
adding get /embark-api/contract/:contractName
adding post /embark-api/contract/:contractName/function
adding post /embark-api/contract/:contractName/deploy
adding get /embark-api/contracts
adding post /embark-api/contract/deploy
adding get /embark-api/blockchain/gas/oracle
adding ws /embark-api/blockchain/gas/oracle
adding post /embark-api/command
adding post /embark-api/authenticate
adding get /embark-api/profiler/:contractName
Starting ipfs process
webserver available at http://localhost:8000
Blockchain node is ready
ipfs process started
Ethereum node detected..
loading solc compiler..
registerAPICall post /embark-api/communication/sendMessage
adding post /embark-api/communication/sendMessage
registerAPICall ws /embark-api/communication/listenTo/:topic
adding ws /embark-api/communication/listenTo/:topic
IPFS node detected..

We could reduce the output to the essentials like:
ready to watch file changes
IPFS node not found, attempting to start own node
Starting ipfs process
webserver available at http://localhost:8000
Blockchain node is ready
ipfs process started
Ethereum node detected..
loading solc compiler..
IPFS node detected..

Similar to what we get in the Logs section within the dashboard view.
We could make this the default behaviour of --nodashboard and introduce a --verbose option that would still enable users to get the whole shebang.
Extra Detail
I've notice that embark run has a --loglevel option. This is set to debug by default. I tried it using the info level instead (as it sounded to me like the least verbose one) but it didn't have any affect on the output at all.
Not sure if this option is actually supposed to do what I'm proposing here.

Turns out I was on a development branch which introduces those logs. Those aren't actually showing up on the latest release.
Thanks for pointing this out @jrainville !
Closing this.


Evaluate removing uid by storing tags in segments

A way to remedy #187 may be to store tags in segments if it does not significantly increase the amount of space and bandwidth used and then remove univariate_id. However, this change needs to be be evaluated in-depth first, as the schema for compressed segments would no longer be the same for model tables with tags and and it may increase the amount of storage and bandwidth required. Removing univariate_ids has multiple benefits in addition to fixing #187, e.g., it makes each segment self-contained which reduces the complexity of data transfer and query processing and it removes the limit on columns in model table. The problem with each model table having different schema for compressed segments could be solved by adding the model tables compressed segment schema to ModelTableMetadata.

After it has been determined if this change should be made and dev/delta-metadata has been merged, the schemas used for the various RecordBatches in ModelarDB should be updated to not use unsigned integers and the number of schemas should be reduced to the fewest possible. While the use of unsigned integers for values like column index may make the semantics more clear, it does not seem to be worth the extra complexity needed to convert back and forth between unsigned integers in memory and signed integers on disk.


Python3-port

This port supports both python2 and python3 agents.

Thanks for the PR! A couple of questions:

Please remove bin/HFO.bak
Was there a reason to split example/high_level_custom_agent into py2 and py3 versions? Ideally, I'd like to have a single file that works for both python 2&3.

The rest looks good, and good work on fixing the Travis file!


Very slow.. Why?

Why is this so slow to fetch results? Like almost 60 seconds or so

import telebot
import asyncio
import re
from telebot.async_telebot import AsyncTeleBot
from EdgeGPT import Chatbot, ConversationStyle
from telebot.util import quick_markup
#Please replace this config
#Please replace this config
#Please replace this config
BOT_TOKEN = '6233730946:AAGSh8jaFV1yIB9Mt2qU6osbL0G_81PIw6o'
ALLOWED_USER_IDS = ['metaspl0it', 'XXXXXXXX', 'XXXXXXXX']
bot = telebot.TeleBot(BOT_TOKEN)
gbot = Chatbot('/home/alessandro/Desktop/BingChatBot/cookie.json','./cookie.json')
not_allow_info = '⚠You are not authorized to use this bot⚠'
What's wrong with this?

callback is really slow, because telegram api does not recommend using async in callback.And I can't find a better way to implement it


LoadHeight implementation looks incorrect

Context
https://github.com/celestiaorg/celestia-app/blob/30aa1b0dddf5871f51b99e60b925dca6caeacc95/app/app.go#L553-L556
Problem
The LoadHeight implementation looks incorrect to me. I think it should be invoking BaseApp's LoadHeight.
Proposal

Write unit tests so that we catch bugs like this
Fix the implementation

Disregard. It looks like Cosmos SDK uses version and height interchangeably in this context which is incredibly confusing. See https://github.com/cosmos/cosmos-sdk/blob/5a8a3885a991c656a9df6e6096f079b69b2ac598/baseapp/baseapp_test.go#L234-L292
Note that LoadHeight is used when we use celestia-appd export and that appears to behave correctly.


remove unnecessary call .clone() in box_convert func

remove unnecessary call .clone() in box_convert func
fix #4091

Hi @developer0hye , thanks for the PR,
Unfortunately I think this call to clone() is here by design: we need the interface to be consistent whether the boxes are converted or not, and thus we always return a copy so as to avoid surprises.
Did you encounter any potential slow down because of this?
I'll close the PR if you don't mind

@NicolasHug
Thanks for your review!


Azure Core API feedback

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
API changes are not detected in this pull request.


feat(clipboard): support windows

refer to https://github.com/yetone/avante.nvim/issues/218#issuecomment-2316030910

There is a problem with the relative paths of images not working in Windows. Will need some time to find out solution.

is there a relative path? I thought the path would be absolute in this case no?

is there a relative path? I thought the path would be absolute in this case no?

I paste the image into the chat box and get a relative path. Is this an unexpected behavior?

The img-clip.nvim supports using the absolute path https://github.com/HakonHarnes/img-clip.nvim/issues/80#issuecomment-2309812863. Windows is working with use_absolute_path=true.


New generic accessors HLC3, HL2 and OHLC4

Add HLC3 ((h + l + c) / 3), HL2 ((h + l) / 2) and OHLC4
((o + h + l + c) / 4) as generic accessors that can be used with different
indicators.  Most indicators access the data with p.accessor(d) and with
the new accessors they can now get the data in various different forms
(and not only the close price what OHLC accessor provides).
Change the VWAP to use p.accessor(d) and HLC3 accessor by default.

Thanks again for the contribution.
Let me have a think about this one. The purpose of accessors is to allow users to redefine how elements are read from their data. By redefining the default method to a calculation it changes the purpose somewhat. I feel these are very specific to indicators or calculations rather than data accessors.


The latest version from NPM is laggy and unresponsive

It takes a lot of time to start and moving cursor along the unstaged files is slow as h*ll.

I couldn't reapear this. Could you plz reinstall it?

Oh, I have found out it works slowly only if connected to the network, it's snappy as usual when disconnected.

hmm.. it's weird. I'm always connected on the network. I'll keep try to find why.


OVS: compare names when checking devices both added and deleted

When processing events from ovsdb monitor, agent checks devices
for which there are both 'added' and 'deleted' events and then looks
for the device in the system to know what event could be omitted.
In some cases event dicts for same port would not be equal:
for example ofports may differ. Thus we should compare device names
rather than dicts.
Please see bug for more details.
Closes-Bug: #1585623
Change-Id: I93e8796ce4a94327c1e96b19f8183c97546e193d

Tests completed:

tox -e pep8
tox -e py27
Manual tests of changed code
Test recreate scenario in https://github.ibm.com/alchemy-containers/networking/issues/82

This pull request is for https://github.ibm.com/alchemy-containers/networking/issues/82.


[Automation] Generate Fluent Lite from TypeSpec computefleet

https://github.com/Azure/sdk-release-request/issues/5595

[Automation] Generate Fluent Lite from TypeSpec computefleet

API change check
APIView has identified API level changes in this PR and created following API reviews.
com.azure.resourcemanager:azure-resourcemanager-computefleet

/azp run java - computefleet - mgmt - tests


Add configurable base path

Added base path param with changeable value "/ngsi-ld/v1" in config files
Used the same base path from config in ApiServerVerticle

Can one of the admins verify this patch?


[RFE] Add delay as an argument in script, instead of specifying explicit sleep

Description
Please add 'delay' as an argument in script instead of specifying explicit sleep
Actual
action: sleep
value: 3
Expected
action{click|hover}  delay

Sleep feature added


Rendering issue with some objects on Chrome

Attach (recommended) or Link to PDF file here:
Test file.pdf
Configuration:

Web browser and its version: Chrome Version 81.0.4044.138 (Official Build) (64-bit)
Operating system and its version: Windows 10
PDF.js version: latest
Is a browser extension: no

Steps to reproduce the problem:

Open https://mozilla.github.io/pdf.js/web/viewer.html
Load the provided .pdf file

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

This looks like a Chrome-specific rendering bug since the file is rendered properly in Firefox 76.0.1 for me.

Looks OK in Google Chrome 88 now, probably fixed by either PR #12812 and/or #12864.

Looks OK in Google Chrome 88 now, probably fixed by either PR #12812 and/or #12864.

The bug is still: it depends of the zoom level.
I filed a bug on chrome's side: https://bugs.chromium.org/p/chromium/issues/detail?id=1170396

The bug is still: it depends of the zoom level.
I filed a bug on chrome's side: https://bugs.chromium.org/p/chromium/issues/detail?id=1170396


what's the parameter 'leaf width' mean

Hi ！
May I ask what's the parameter 'leaf width' mean? Looking forward for your reply!

Hi,
In the original August pre-print we trained FFFs that could have multiple neurons as leaves of the FFF trees (rather than the leaves being just single-neuron nodes just like their parents). There, the leaf_width is just the width (i.e. the hidden width) of each leaf network of the tree.
This has proven to be less efficient than having all leaves have a single node, and so we dropped it when working towards UltraFastBERT.


Redefined ComplCaseSensitivity as a proper sum type. (#509)

Description
This is my first time submitting a pull request of any kind, so please tell me if I've done anything incorrectly.
This PR is an implementation of the suggestion in issue #509, with all relevant functions changed so as to expect the rewritten datatype.
Checklist

[✔] I've read CONTRIBUTING.md

[✔] I tested my changes with xmonad-testing

[✔] I updated the CHANGES.md file

[✔] I updated the XMonad.Doc.Extending file (if appropriate)

Thank you everyone for being so kind in dealing with this, especially with such a small issue. I have implemented the changes you all have requested. Unnecessary parentheses have been removed and the equality issue has been solved with a pattern match.

Thanks!


Refactor serialization of first argument in Node class

Updated the serialize_first_arg_tensor function in the Node class to improve handling of various types of first arguments passed to layers.

If the first argument is a Keras tensor, it is now serialized with additional metadata including the layer name, node index, and tensor index.
For other types such as NumPy arrays, tensors, integers, floats, booleans, and strings, they are directly serialized without additional metadata.
Added a ValueError raise statement for invalid first arguments, ensuring that only supported types are accepted.
Updated the map_arguments method documentation to reflect the changes in serialize_first_arg_tensor.

Hi @MadhumithaKolkar It looks like your PR relates to the Keras component. Please submit it to the github.com/keras-team/keras repository instead. Thank you for your contribution!
@fchollet, @qlzh727


namespace with : causing problem with iterator

Please check if the PR fulfills these requirements

[X] Followed the Contributing guidelines.
[X] Tests for the changes have been added (for bug fixes/features) with 100% code coverage.
[X] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
This adds a failing test that shows how ':' in the namespace causes the Redis iterator to fail.
There is some dumping to the console to see the issue (this is from running the test in the @keyv/redis package):
key testv1:3:3 value 13
  ✘ [fail]: test › iterator() handles : in keys X
key testv1:2:2 value 12
key testv1:4:4 value 14
key testv1:1:1 value 11
key testv1:0:0 value 10

This is in response to the issue https://github.com/jaredwray/keyv/issues/924

@markNZed - I am wondering if we should hold off on this fix as there are plans to make namespace a function in the next 3-4 months. Thoughts?

All I provided in the PR is the test case, not a fix. Maybe that is not what is intended for PR ? I agree that it makes sense to wait for the planned changes rather than fixing code that will be replaced. Still I would add this test. Maybe just leave the PR open and copy the test when the new code is available?

@markNZed - will close this out as the pull request is used to fix any issues. Will move your code example to the issues as we can look at it there.


[1.18.2] Structures have lots of spawning issues and inconsistencies

Such as large flat overhangs where it needs a bigger flatter area, corners being empty from what I'm presuming being worldedit copies. Stuff like that, can catalogue with pictures if needed for specific ones. Other than that great mod :D

Please send some images

I don't use worldedit, the corners of many structures are filled with void blocks which are replaced with terrain blocks on generation. if there is no terrain that could cause the empty corners


Troubles with Travis

There is something weird with the Travis setup on the JuliaCI organization. It’s using staging.travis-ci.com, which I think is the experimental version of Travis.
As a result, some things that work on travis-ci.org don’t work on staging.travis-ci.com. For example, submission to Coveralls works perfectly from travis-ci.org, but doesn’t work from staging.travis-ci.com.
Could we uninstall staging.travis-ci.com from JuliaCI and install the regular Travis (travis-ci.org) on all the JuliaCI repositories?
cc: @ararslan @StefanKarpinski

Done, I think.

Does not seem to be working, see e.g. https://github.com/JuliaCI/CoverageCore.jl/pull/15

Can you go here: https://travis-ci.org/JuliaCI/CoverageCore.jl
And try to turn it on?

Now we are cooking with gas.
One last request- can you fix or remove the branch protection settings for the master branch of CoverageCore.jl? The current branch protection settings use the incorrect staging.travis-ci.com status check.

I kept branch protection but removed the requirement that CI passes.

Perfect!

I think all the problems are fixed now.


Possible null exception

The value of restError may sometimes be null, although it is not expected. However, ReadFromJsonAsync could still return null. Therefore, we need to ensure that the values of restError.Key and restError.Message are not null as well.
Although it is unlikely that we will receive null, we can fix this issue by either suppressing null with ! (fastest, but not safest!) or double-checking all possible null properties to ensure they are not null (suggested one although it could be unnecessary!).

When the response has an error status code and the Request-ID response header and the response content type is application/json, we can be sure that it was handled by our own middleware and the schema is guaranteed. Therefore, we can safely use the ! operator in this case.


Handle Blob Create when the underlying registry doesn't provide 'Docker-Upload-UUID'

Some registries, such as ECR don't provide a Docker-Upload-UUID HTTP header when starting a blob upload. So we can't rely on that, which then fails when we try to generate the Location header we return (in blobupload.go).
This fallbacks to try reading the UUID from the Location header returned by the underlying service. If we still don't have any UUID, it then returns an error.
I didn't remove @dmcgowan's TODO because we're technically still not checking for invalid UUID, only for empty strings.

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "blob-create-uuid" git@github.com:dmathieu/distribution.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842358448512
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

@caervs This is another fix for #2922


ci: remove next from build targets

Overview
We no longer use next

Next branch is removed, so merging.


Modified spacing in UG

Pull Request Test Coverage Report for Build 337

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 54.957%

Totals

Change from base Build 336:
0.0%

Covered Lines:
1591

Relevant Lines:
2895

💛  - Coveralls


Fixes test:unit

Makes npm run test:unit working again by:

syncing snapshots (npm run test:unit:updatesnapshot)
disabling one failing test in packages/core/src/features/cluster/refresh-accessibility-technical.test.ts
disabling threshold for coverage

@robertobandini Do you need any help with the GHA pipelines?


Q: Zones, Regions, Ribbon and Eureka

I have been looking into making my app using Spring Cloud highly available on Bluemix.  I started out deploying Eureka to our US datacenter and UK datacenter and set them up as peers.  This worked fine.  Instances of my services registering themselves in each region were being replicated between the peers.
I then started reading some of the Eureka documentation and realized they do not recommend having Eureka instances across regions being peers.  However they are making an assumption you are running Eureka in AWS, and you have the extra redundancy of zones within a region.  In the Bluemix case, that is not the case (yet).
What I would like to have happen is if a service in one Bluemix region is down that services flip over to use a service in another region.  So it sounds like in Eureka terminology I want to treat a Bluemix region as a zone instead.  Does that make sense?
In addition I want to make sure services in the same region always use other services in that region if they are up.  Eureka sounds like it supports this, but again only with a "zone" and not across a region.
So I guess my question is what is the right way to configure Eureka clients and servers to accomplish this?  The documentation only shows how to leverage the default zone and from what I can tell by reading the Eureka documentation it makes a lot of assumptions that zones are referring to AWS zones and if you are running in another cloud environment those assumptions might break things.

OK so i saw a small section about Zones and Ribbon in the documentation.  Sounds like maybe approximateZoneFromDomain is something that might help me.  Each Bluemix region has a different domain (the use is mybluemix.net the UK is eu-gb.mybluemix.net).  Thoughts?
Also I looked through the code for approximateZoneFromDomain but only found a reference in to that string in the documentation.  In the code there is a property called approximateZoneFromHostname, is there a typo in the documentation?  What is the complete property name I should be setting?  Do I set it to true/false?

Looks like the correct property value is ribbon.eureka.approximateZoneFromHostname.

created issue #314 to track the above documentation issue

Also see issue #315 which I think also is related to making my above scenario work

I think I have resolved the problems I had in #314 and #315 so we can close this issue

meet the same question, thanks a lot


The ANSI 'hidden' color code does not seem to be supported in the terminal

Issue Type: Bug
It doesn't appear that the 'hidden' ANSI escape is supported in the VSCode terminal.  Specifically, I'm running some JS code (NodeJS) and doing a console.log command using the 'hidden' color code sequence but the text is displaying in the default font/color rather than being hidden.
VS Code version: Code 1.50.1 (d2e414d9e4239a252d1ab117bd7067f125afd80a, 2020-10-13T15:06:15.712Z)
OS version: Windows_NT x64 10.0.18362
Extensions (2)

Extension
Author (truncated)
Version

monokai-charcoal-high-contrast
74t
3.2.0

uniform-dark-theme
sae
1.5.0

(3 theme extensions excluded)

It's definitely supported:

You're probably hitting an issue with invisible attribute support in either conpty or the shell you're using since you're on Windows. It looks like Windows Terminal also supports it (running wsl) which uses a newer version of conpty, so it will either come to VS Code over time as Windows gets updated or it might not get fixed if your shell is the one manipulating the sequence.

It's definitely supported:

You're probably hitting an issue with invisible attribute support in either conpty or the shell you're using since you're on Windows. It looks like Windows Terminal also supports it (running wsl) which uses a newer version of conpty, so it will either come to VS Code over time as Windows gets updated or it might not get fixed if your shell is the one manipulating the sequence.

@Tyriar Thanks.  I'm on Windows 10 and my VSCode terminal is set to 'cmd'.  In the 'shell' dropdown I only have 3 choices ...

Maybe I need to switch to a different shell in order for the 'hidden' char code to work?

@kretschmannj if cmd is your main shell I'd recommend using shell launcher here https://marketplace.visualstudio.com/items?itemName=Tyriar.shell-launcher
I can say from experience after delaying so long it was worth learning a little bit of PowerShell to replace the little bit of cmd I needed as PowerShell continued to get updates today.


Re-compute track manager methods only when required

Description
Wraps methods in use callbacks. Simplify gathering metadata.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to
not work as expected)

Why FCE-461 is linked here? This ticket is also set as In Review


Feature request: move selection up or down

System : Macos
Version 0.5.9-nightly (0.5.2129)
I tried to set a setting in experimental.viml to move selection up or down, based on this https://vim.fandom.com/wiki/Moving_lines_up_or_down
Here is what I tried :
    "vnoremap <C-Up> :m '<-2<CR>gv=gv",

Output :

I suspected the error came from the first ', so I also tried without it:
    "vnoremap <C-Up> :m -2<CR>gv=gv",

It almost works, but the final gv seems to have no effect, and I lose selection after having moved the selection one line up.

ah, I see there is a related issue https://github.com/onivim/oni2/issues/3325 already opened. I'm closing this one :)


Generated FrontDoor implementation doesn't preserve existing state of resource

I checked file generated for Terraform here:
https://github.com/VSChina/magic-modules/blob/azure_backend/build/azterraform/azurerm/resource_arm_front_door.go
It seems like resource_arm_front_door doesn't include definition of subresources.
If I understand correctly, if this implementation is applied on existing Front Door instance that has existing subresources, they will be removed when CreateOrUpdate function is called.
I think this is not correct behavior.

This is the wrong one, ignore it.


refactor for unit parameter

This PR brings turf-hex in line with the other turf grid modules (turf-point-grid, turf-square-grid, turf-triangle-grid)

add a required unit parameter
change size (radius) param to cellWidth
refactor tests for easier verification
refactor benching to be comparable to other turf grid functions
change name of module from turf-hex to turf-hex-grid

Great! :+1:


site domain alias transfer

are we ready to figure this out @dfalster ?

yes! relevant info is here: https://docs.netlify.com/domains-https/custom-domains/
Looks like there's steps on both netlify side and domain side, i.e. whoever you used to register the domain.

We've implemented the redirection. Seems to work!
Only issue is that a warning pops up, suggesting one of the setting isn't quite right

Solved! I needed to renew the SSL/TLS certificate in netlify (under Domain management, HTTPS).


creating a fake commit to test CI pipeline

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

If this PR is for a new extension or change to an existing extension, use the following to try out the changes in this PR:
docker run -it microsoft/azure-cli:latest
export EXT=<NAME>
pip install --upgrade --target ~/.azure/cliextensions/$EXT "git+https://github.com/gauravsaralMs/azure-cli-extensions.git@users/gsaral/validatePrBuild#subdirectory=src/$EXT&egg=$EXT"

Taking the liberty to close this


feat: support TOML in config

Follow-up on #213
Closes #193
A few problems with existing approach:
Config file of form
ca = "testdata/ca.crt"
cert = "testdata/server.crt"
key = "testdata/server.key"
store = "testdata"
oidc-secret = "mysecret"
oidc-client = "myclient"
oidc-label = "mylabel"
oidc-issuer = "myissuer"

fails to parse:
error: Found argument 'ca = "testdata/ca.crt"' which wasn't expected, or isn't valid in this context

USAGE:
    drawbridge [OPTIONS] --store <STORE> --cert <CERT> --key <KEY> --ca <CA> --oidc-label <OIDC_LABEL> --oidc-issuer <OIDC_ISSUER> --oidc-client <OIDC_CLIENT>

For more information try --help

Same behavior with:

ca="testdata/ca.crt"
ca "testdata/ca.crt"
ca testdata/ca.crt

The implementation expects the file to contain the actual commandline flags in the file, that means it's just a convenience over doing drawbridge $(cat args), which is not what we want.
With this PR in place we enforce TOML in config files, which means that the configuration file format is non-surprising and obvious
Example error:
cargo run -- @config.tom
    Finished dev [unoptimized + debuginfo] target(s) in 0.12s
     Running `target/debug/drawbridge<EMAIL_ADDRESS>Error: Failed to parse arguments

Caused by:
    0: failed to read config file at `config.tom`
    1: No such file or directory (os error 2)

Is it worth supporting TOML here? I'm deliberately following the convention of Python's argparse module and C#'s responsefile formats, where the configuration file just contains raw command-line flags (separated by linebreaks in Python's case (and in my previous PR, though it would be trivial to support them without linebreaks (as in C#) by pulling in the shlex crate)).
In addition, the current approach is more natural than the TOML approach, since we would need to manually translate many TOML datatypes to their CLI equivalent. For example, it looks like the current PR would turn foo=true into --foo true, but the equivalent of that would just be --foo. For options with multiple values it would need to be turning foo=[1,2,3] into --foo 1 2 3. And I don't even know the best way to represent passing in options that don't have named flags; the current approach supports turning (to use Enarx as an example) enarx run foo.wasm into enarx run @config; what would the TOML key be there? With all this processing going on a user will have to manually reverse our TOML processing in their heads just so that we can turn their TOML back into a CLI argument... what are the advantages of forcing them to do that?

(Python docs, for reference: https://docs.python.org/3/library/argparse.html#fromfile-prefix-chars )

Is it worth supporting TOML here?

Yes, we want to provide users functionality to configure the service via a config file format they already know - TOML or YAML most probably.
This should be the default way of configuration, whereas the command-line arguments serve as overrides.
The problem with the current approach is that this model is reversed - instead of writing a config file, users are expected to put their arguments in a config file. That's not a big improvement over start.sh looking something like this:
exec drawbridge --ca <ca-path> --cert <other-path> ...

And we do not want our users (or ourselves) to have to resort to that, instead we want to have structured configuration files, where each field is validated. We want to provide users with clear error messages when config file is not correct or if they've used a config parameter, which is not supported. In any case, the config file comes first and cmdline arguments are really just for development purposes.

In addition, the current approach is more natural than the TOML approach, since we would need to manually translate many TOML datatypes to their CLI equivalent

We only have strings now

For example, it looks like the current PR would turn foo=true into --foo true, but the equivalent of that should just be --foo

Fixed

And I don't even know the best way to represent passing in options that don't have named flags; the current approach supports turning (to use Enarx as an example) enarx run foo.wasm into enarx run @config; what would the TOML key be there?

It is not relevant for Drawbridge, as it's not a tool that users will interact with directly, instead it's a backend service, which will be configured via a configuration file

We want to provide users with clear error messages when config file is not correct or if they've used a config parameter, which is not supported.

One of the goals of preprocessing the arguments is that we get these sort of error messages for free from Clap.
If we want to have a "configuration-first" API, then perhaps we should only support using configuration files and get rid of the CLI entirely?

In fact, the current configuration file approach does not provide any value, since user

We want to provide users with clear error messages when config file is not correct or if they've used a config parameter, which is not supported.

One of the goals of preprocessing the arguments is that we get these sort of error messages for free from Clap.
If we want to have a "configuration-first" API, then perhaps we should only support using configuration files and get rid of the CLI entirely?

We could, but having both is nicer, in particular for development and overrides.
Once clap supports configuration files we'll just use that feature, but for now we need to have a way to store config in a usual config file (toml, yaml, json, ??) to be able to deploy this.

Once clap supports configuration files we'll just use that feature

Has the Clap maintainer suggested that this will happen? Even if they did, I would expect Clap to follow Python's and C#'s precedent, doing the equivalent of my prior PR. Is there any CLI library that supports configuration in some other way? I'm looking at Go's cobra/viper right now, but it looks like there's no integration between them when it comes to CLI vs. config file.

Once clap supports configuration files we'll just use that feature

Has the Clap maintainer suggested that this will happen? Even if they did, I would expect Clap to follow Python's and C#'s precedent, doing the equivalent of my prior PR. Is there any CLI library that supports configuration in some other way? I'm looking at Go's cobra/viper right now, but it looks like there's no integration between them when it comes to CLI vs. config file.

Viper does have support for config files.

reading from JSON, TOML, YAML, HCL, envfile and Java properties config files
from https://pkg.go.dev/github.com/spf13/viper#section-readme

Regardless of all of this, people running Drawbridge should be able to configure it, to maintain the configuration - perhaps put in version control or generate it using some tool. There should be comment support in the config file.
We probably want to provide a default/template config file with commented-out /documented options for people to start with.
We want the config file options to be strongly-typed
We currently do not have a config file - we have functionality to read flags from a file, but that is not a config file.

Examples of how configuration works for production-grade services:

https://redis.io/docs/manual/config/
https://www.postgresql.org/docs/current/config-setting.html
https://www.nginx.com/resources/wiki/start/topics/examples/full/
https://www.keycloak.org/server/configuration

Using flags as configuration file format may be common in Python ecosystem, but is not relevant for us

Viper does have support for config files.

Sure, but I'm asking about integration with the CLI.

If Clap does not support this, then we'll do it ourselves, but we can't put a bunch of flags and arguments in a file and call it configuration.

Sure, but that raises my earlier question, why not just get rid of the CLI entirely at that point?

Viper does have support for config files.

Sure, but I'm asking about integration with the CLI.

It is fully integrated, first the config file is parsed and then everything else.

If Clap does not support this, then we'll do it ourselves, but we can't put a bunch of flags and arguments in a file and call it configuration.

Sure, but that raises my earlier question, why not just get rid of the CLI entirely at that point? The whole problem of the first approach was that adding a config file makes the Clap-generated output quite bad, possibly to the point of uselessness.

Yes, there's definitely room for improvement, but the flag/config parameter names match and values expected do as well.
We'll file an issue about this and do it "properly" once we have the bandwidth for that, but we need something that works today.

It is fully integrated, first the config file is parsed and then everything else.

Ok, so the integration you're asking for is having the config tool be capable of emitting shell-parsed arguments rather than having the CLI library understand config files. As long as we're preprocessing the arguments it makes sense to continue using Clap.

How about a config file which can have inline certs & keys? I've seen this for VPN client configs, it's convenient.

How about a config file which can have inline certs & keys? I've seen this for VPN client configs, it's convenient.

Sounds like a great idea, but not for this PR, we have to have something simple to start with and expand on that later. This could be done as a custom TOML-based config file format.
Please file an issue about it.
Note, that we cannot implement it if our config file format is a bunch of command-line arguments as it is currently