HEME only partially aromatic

Describe the bug
Using the SMILES string from pubchem for heme (https://pubchem.ncbi.nlm.nih.gov/compound/Heme#section=IUPAC-Name), CC1=C(C2=CC3=NC(=CC4=C(C(=C([N-]4)C=C5C(=C(C(=N5)C=C1N2)C=C)C)C)CCC(=O)[O-])C(=C3C)CCC(=O)O)C=C.[Fe+2],   I'd expect all three nitrogen rings to be aromatic.
To Reproduce
>>> from rdkit import Chem
>>> heme = Chem.MolFromSmiles('CC1=C(C2=CC3=NC(=CC4=C(C(=C([N-]4)C=C5C(=C(C(=N5)C=C1N2)C=C)C)C)CCC(=O)[O-])C(=C3C)CCC(=O)O)C=C')
>>> Chem.MolToSmiles(heme)
'C=CC1=C(C)c2cc3[n-]c(cc4nc(cc5[nH]c(cc1n2)c(C)c5C=C)C(C)=C4CCC(=O)O)c(CCC(=O)[O-])c3C'

Expected behavior
I think that I'd expect all ring envelopes of the heme to be aromatic. I see the same issue with porphyrin- https://pubchem.ncbi.nlm.nih.gov/compound/Porphyrin#section=IUPAC-Name

I believe that this is expected behavior
Here's a drawing of the core of your heme structure with the aromatic bonds highlighted:

Two of the five-membered rings are aromatic (they have 6 pi electrons) and two are not (they have 5 pi electrons). The entire inner envelope is aromatic (it has 18 pi electrons), but the RDKit doesn't find any path involving the "outer" two bonds of the non-aromatic five-rings. I did a bit of mental enumeration and didn't find anything to contradict that, but if you do see something, please let me know.

I guess I also cannot unless I delocalize the negative charge to 18 or 5. I'm going to close this because it's not a bug.


derives Decoder and derives Codec.AsObject fail with -Yexplicit-nulls compiler option

Scala version 3.0.0
Circe version 0.14.1
When the -Yexplicit-nulls compiler flag is enabled, Decoder derivations like the following fail to compile:
case class Foo(bar: String) derives io.circe.Decoder

I get the following as the first error:
[error] -- [E007] Type Mismatch Error: /Users/barnardb/some-project/src/main/scala/c.scala:1:45
[error] 1 |case class Foo(bar: String) derives io.circe.Decoder
[error]   |                                             ^
[error]   |                               Found:    Null
[error]   |                               Required: Left[io.circe.DecodingFailure, ?]
[error]   | This location contains code that was inlined from Derivation.scala:77```

As one might expect with the derivation for Decoder not working, the following Codec.AsObject derivation also fails:
case class Foo(bar: String) derives io.circe.Codec.AsObject

Background
Scala 3 has a -Yexplicit-nulls compiler option that enables explicit nulls. When this flag is enabled, AnyRef types such a String no longer accept null as a value, requiring values to be explicitly marked as being in a union with the Null type in order to be nullable. E.g. val s: String = null fails to typecheck, but val s: String | Null = null does. This allows more safety around the use of nulls.
Note that if explicit nulls are not being used then the type String | Null is equivalent to String, so by using explicit … | Null types for the rare Scala types that are actually nullable we can produce code that works regardless of whether the -Yexplicit-nulls option is in use or not.
There is an unsafeNulls language feature that can be enabled in a particular scope by importing scala.language.unsafeNulls to suppress most of the effects of unsafeNulls in code that needs a bit of an escape hatch.
Workaround
Here are some workarounds using unsafeNulls that can be used by users of -Yunsafe-nulls until this issue is addressed in Circe. The workarounds use Codec.AsObject, but they also work with the appropriate adjustments for Decoder.
The code compiles if we enable the unsafeNulls language feature by importing scala.language.unsafeNulls:
import scala.language.unsafeNulls

case class Foo(bar: String) derives io.circe.Codec.AsObject

For top-level declarations though, this prevents us from taking advantage of most of the effects of explicit nulls in the entire file.
If we're willing to repeat code for every type that derives the typeclass, we can move the import to the companion object and reduce the unsafeNulls scope to the companion object:
case class Foo(bar: String) derives io.circe.Codec.AsObject

object Foo {
  import scala.language.unsafeNulls
}

But in that case we may as well stop using derives, and declare the given typeclass instances manually, limiting the unsafeNulls scope to their definitions:
case class Foo(bar: String)

given io.circe.Codec.AsObject[Foo] = {
  import scala.language.unsafeNulls
  io.circe.Codec.AsObject.derived
}

Alternatively, we can define an extension to the trait, and have its derivation use unsafeNulls. This is what I'm currently doing in my codebase, because it lets me keep the derives style, most of the workaround lives in one place, and it should be easy to remove the shim later with a trivial find-and-replace:
/** Shim until `derives Codec.AsObject` works with explicit nulls */
trait CodecAsObject[A] extends io.circe.Codec.AsObject[A]

object CodecAsObject {
  inline def derived[A: scala.deriving.Mirror.Of]: CodecAsObject[A] = {
    new CodecAsObject[A] {
      val derived = {
        import scala.language.unsafeNulls
        io.circe.Codec.AsObject.derived[A]
      }
      def encodeObject(a: A): io.circe.JsonObject = derived.encodeObject(a)
      def apply(c: io.circe.HCursor): io.circe.Decoder.Result[A] = derived.apply(c)
    }
  }
}

case class Foo(bar: String) derives CodecAsObject

It looks like the fix might be as simple as changing lines 77 and 160 of Derivation.scala from
var failed: Left[DecodingFailure, _] = null

to
var failed: Left[DecodingFailure, _] | Null = null

I'd be happy to make a pull request. I'm not sure about how to avoid regression though. I could look into adding -Yexplicit-nulls to the relevant test module. Or maybe a new test module specifically for this so as not to change anything else?

Already fixed after release 0.14.4. Closeable.


[ bug ] apk add --update sudo

version:
REPOSITORY                                                             TAG          IMAGE ID       CREATED         SIZE
casbin/casdoor                                                         v1.293.0     bc2312884fcb   5 hours ago     98MB

Chances are it's your network

agree with @dmzlingyin
Closed here


[BEAM-11841] Optimize byte size calculation of lazy iterables

Update the byte size calculation for lazy iterables after processing instead of counting output stream

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Java PreCommit

R: @boyuanzz

R: @robertwb


Automatic refresh after folder update

What's the Problem?
When the contents of the folder are updated, such as copying new files into the folder, we need to refresh manually to display the new files.
Solution/Idea
Automatic refresh after folder update
Alternatives
Automatic refresh
Priorities

Capability
Priority

This proposal will allow developers to accomplish W
Must

This proposal will allow end users to accomplish X
Should

This proposal will allow developers to accomplish Y
Could

This proposal will allow end users to accomplish Z
Won't

Files Version
No response
Windows Version
No response
Comments
No response

Merging with #6564


fix: pack build outpout on Windows

Changes

:bug: Fix broken output of pack build on Windows (there were issues with coloured output).

PTAL @lance @lkingland


React 15 update

Currently it has peerinvalid errors in the on-debugger build for npm@2.
Also, the react-switcher still have<EMAIL_ADDRESS>dependency, @zalmoxisus maybe you should use ^0.14.0 || ^15.0.0 as a peer dependency?

If the problem is only with react-switcher, I'll update it. Thanks!

Oh, should we have "react": "^15.0.2" not "react": "^0.15.2"?


fix(webfrontend): Disable warnings caused by flat

Summary
After this change no warning caused by flat is displaying.
Details
Add the flat package to allowedCommonJsDependencies option in the build options located in angular.json file.
Screenshots:

References
GitHub related issue
Angular documentation

Update issue's status on backlog board.


Getting the word 'error' instead of Version number on "ng --version"

OS?

Windows 8.1

Versions.

Node: 7.7.1
npm: 3.10.2

Mention any other details that might be useful.

ng --version returns following result with error on last 5 results:
@angular/cli: 1.0.0-rc.1
node: 7.7.1
os: win32 x64
@angular/compiler: error
@angular/compiler-cli: error
@angular/core: error
@ngtools/json-schema: error
@ngtools/webpack: error
Here is the path from where I executed ng --version command.
C:\Users\<YourUserName>\AppData\Roaming\npm\node_modules\angular-cli> ng --version
I do not get above output if I run ng --version command from any other windows path.

The logic to determine whether the current directory is within a CLI project is to check the dependencies within package.json. The CLI thinks it is within a CLI project here so it is trying to find the versions of the dependencies you see there, but they're not found so it shows error.
I'm not too concerned about this, can you please retry from these two locations:

A folder in you dev environment that is not a CLI project.
A folder inside of a CLI project

The first should yield just the CLI's version.
The second should yield the CLI's version as well as the other dependencies you see listed above.

Try executing:   ng -v
Hope it helps.

Run npm install, fixed it for me.

This worked for me:

delete node modules folder
npm install


Ability to pull service images if newer version available

Hello,
first of all would like to say thank you for such an awesome CI system. I'm going to use it heavily now)
So during my work I face the following issue (as of 0.3.0-alpha0)
Say we have following config:
image: quay.io/dennybaa/droneunit-ubuntu
env:
  - BUILDHOST=st2packages-buildenv-deb
script:
  - ./.drone/build.sh
services:
  - quay.io/stackstorm/st2packages-buildenv-deb

Service image update is impossible
When I click rebuild or even update the service image this image doesn't get updated during a new triggered build or during manual rebuild. It's looks that current implementation doesn't handle the described situation.
If builds are slow and or if we have parallel builds and service image has been updated in-between runs then we end up referencing the same image (the first one). It's not the best behavior, imo drone should be able to clone service images similar way it does for build images.
However there's an unclear moment if a build was performed with a previous version of service container, and then I decide to rebuild it manually - what version should be used.
Cheers!

Details: particular tags should be update when service image is pulled,
since doing docker pull registry_path  doesn't update the whole family, ie.
docker pull quay.io/dennybaa/droneunit is not the same as
docker pull quay.io/dennybaa/droneunit:trusty-upstart

marking as started because the 0.4 yaml has a pull flag. When pull: true drone always downloads the latest image. This works for build images, plugins and service images

awesome!

marking as closed in 0.4 branch


Can't connect dronekit scripts to my solo copter(Pixhawk4 controller), although the example scripts work all fine with SITL instance

when I try to run any one example script onto my UAV(Pixhawk4 controller), it doesn't work well, problem shown as:

All the examples work fine with SITL instance, as well as onto my Mavproxy.
So i am quite confused why my UAV can connect mavproxy while not the example scripts.
and I am pretty sure my port "/dev/ttyACM0" is correct.

hi , did you find a solution ? I'm facing the same problem

@mohamadsaab hi! sorry for so late reply.
so i don't remember what reason it was exactly, but i am sure the problem should came out of two possible scenarios:
no.1:in the flight controller side, you need to choose either micro usb port or TELEM2 port, i am using micro usb port to connect this time while I heard some companion computers don't work with TELEM2 port. so when i use TELEM2 port to connect with, flight controller always fails to connect my script.
no.2:   in the NUC(companion computer) side, there are usually 3 or 4 usb ports on the computer right? so I probably made a mistake to connect a port with identifying a wrong port name, like the port i was connecting is ACM1, but i typed : /dev/ttyACM0. so it failed to callback my script.
Hope above explanations can help you even a bit.

Ok I understand . I am using navio2 which is HAT for raspberry pi so i can't change the port unfortunately . I thought it would be another reason but thank you for replying.


Introduce API 1.30 (CPLib-based CENC PAVP support)

Signed-off-by: Dmitry Brazhkin<EMAIL_ADDRESS>

Please update documentation along with API change.

done

windows build fails for some reason...

windows build fails for some reason...

Looks like infrastructure issue. I've committed once again to restart buildbot


Nakedo Says Music Module dosent exist

everytime anyone on my server attempts to use the command "!!" nothing happens at all. I tried a few commands and anytime i said "Music" as the module she said it didnt exist. I also used .modules and it only listed out
List of modules:
• Help
• Administration
• Utility
• Permissions
• Conversations
• Gambling
• Games
• Searches
• NSFW
• ClashOfClans
• Pokegame
• Translator
• Customreactions
Type "-commands module_name" to get a list of commands in that module.

Public Nadeko does not play music.
For music module you have to host the bot yourself.
http://nadekobot.readthedocs.io/en/latest/Readme/


⚠ ku-s has degraded performance

In 6008125, ku-s ($KU_API_STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 9780 ms

Resolved: ku-s performance has improved in db4d661 after 8 minutes.


VK_EXT_debug_utils nor VK_EXT_debug_marker need a way to query whether frame is actively captured.

Description
When we inject groups and markers around source code all the time, we see the slowdown from the capture layer on sources.  On one platform, I see as much as 40ms from leaving markers on with the RenderDoc capture even though we're just running and not capturing the build.
I can see some resource overhead from keeping ref counts alive on resources in case there's a capture, but I wasn't expecting this much of a slowdown coming from PIX and other capture tools.  I believe we only have access to extensions on some platforms, and can't integrate RenderDoc API directly.  So this would need to be supplied in an extension.
On Metal, there is an isCapturing call that we can tie all of our code to.  Something similar needs to be exposed in these extensions.
// called once per frame to see if capture is enabled
void Foo::BeginFrame()
{
	MTLCaptureManager* captureManager = [MTLCaptureManager sharedCaptureManager];
	m_capturingGPUFrame = captureManager.isCapturing;
}

// this is tested before calling our wrappers to fire off
// pVkCmdBeginDebugUtilsLabelEXT and pVkCmdEndDebugUtilsLabelEXT
bool Foo::IsDebugMarkerEnabled() const
{
	return g_renderer->m_capturingGPUFrame;
}

Steps to reproduce
Do a capture with a lot of groups and markers in it.
Note perf with and without perf markers.
Disable perf layer, and not 40ms faster.   This is platform specific.
Environment

RenderDoc version: v1.12
Operating System: Windows 10 Pro
Graphics API: Vulkan

I would be very surprised if the overhead of command buffer markers was measurable, certainly not to the degree of 40ms. Not unless you're doing an obscene number of those calls. There's not much that can be done to optimise those calls and I don't want to start trying to micro-optimising unless I'm sure that's the problem.
Can you please share a reproducible test case where there's high overhead from the marker calls so that I can investigate in detail?

I think the capture slowdown is actually the accumulation of commands on this platform.  I can't share the code or platform in this case.  It's more complex when capture is always on, and you want testers to be able to send RenderDoc captures easily.
But I also think extensions should offer ways where you can optimize out function and string work during non-capture situations.  Anyways, I liked that Metal offered a test for this, and we use that call to stop injecting any strings into the command buffer until a capture occurs.
In reading about RenderDoc, there was only a test for this that worked on Windows only and not on any other platforms.  If this were formalized into the Vulkan extension specs, then all systems could just call that.

I'm afraid I don't understand what you're talking about, what accumulation of commands?
If this only happens on one platform then it doesn't sound like a RenderDoc bug to me, since the same code runs on all platforms and will have effectively the same overhead. Maybe there's some other layer that's slowing down unnecessarily on these commands.
I'm also not sure what test you're talking about, there is no windows-only test. With a handful of exceptions RenderDoc features work on any platform where possible, certainly anything relevant to debug markers or API interfaces.
However calling the marker label functions unconditionally (except in e.g. a release build) should have negligible performance overhead. It doesn't sound like you've measured what the problem is, trying to avoid calling these functions except mid frame capture is a hack because these functions shouldn't be expensive in the first place. It also risks missing some command buffers if they start recording before the capture begins.

No, I isolated it to enabling the RenderDoc capture extension on this platform and then not setting that.  We ended up only enabling this extension at startup to record commands.  I was hoping to leave the capture on, but my colleagues weren't impressed by the CPU hit from our perf tools.
I guess you don't maybe have an API in RenderDoc to see if a capture is in progress.  I saw this comment on the In Application API but I guess it's just about dynamic loading of RenderDoc.  "This is not supported on Linux or Android due to the differing methods of hooking and only Windows supporting injection at runtime".
I didn't say the markers were the cause of the slowdown above, but I just liked the low call overhead from perf tools like Metal GPU capture when capture is not active.   I can only assume the slowdown we see is the capture of command and resource on every frame by the capture itself.  Even though we only snap a one or less frame in a run.  Sorry, but we don't have the RenderDoc sources in this case on this platform, so I'm guessing at the CPU slowdown.

OK it's very misleading to say that you see slowdown from leaving markers enabled when actually it sounds like markers have nothing to do with it and you're seeing general overhead from launching your program from RenderDoc. I don't expect it would make any difference at all if you were able to enable or disable markers only when capturing because the overhead will be coming largely from other places, and honestly I would expect that to be true for all tools. Depending on the platform and how the tool works it may have different overheads while capturing or idle, it's hard to compare without specific examples.
I do profile and optimise whenever possible to keep the overhead to a minimum where possible and improve things, but I do need to be able to run an actual or representative workload to be able to see where the problems are. In the past few versions I've applied optimisations based on significantly complex vulkan applications and I've been able to limit the background overhead to a reasonable degree. Generally I aim for single-digit millisecond overhead but there will always be some and it depends on what the application does, it's quite possible to hit nasty API cases that need to be specifically optimised for. Some of these optimisations are application and GPU specific, so it would help to know which platform are you talking about. Is it an android device of some kind?
The in-application API is indeed available on every platform. The comment you found is specifically about late-loading the renderdoc module which is only supported on windows, but every platform can query for the appropriate renderdoc module and access the API. However as I say above I believe you are completely on the wrong track at trying to disable the markers because I don't expect it will make even a fraction of a difference.

Closing as resolved over email.


Output in repeater not working

Using output in the repeater is not working. I have been trying to use a text field to add a font-size (not using the typography), but having the value of e.g.: 14px in the field is not change the link element.
I am using the latest version.
In the fields area of the repeater, I added the following:
'header_left_font_size' => [
    'type'        => 'text',
    'label'       => esc_html__( 'Font size', 'kirki' ),
    'section'     => 'header_left_section',
    'default'     => esc_html__( '14px', 'kirki' ),
    'transport'   => 'auto',
    'output'      => [
        [
            'element'   => '.mini-text-icon',
            'property'  => 'font-size',
        ],
    ],
],

Can anyone confirm that this is actually the case?

Hello and thank you for reporting this issue.
We are closing most open GitHub issues with the release of Kirki 4 to start fresh with this major release.
If you are still running into issues after you have tested your theme with Kirki 4, please let us know so we can reopen the issue.
Please note that Kirki 3 is no longer actively supported. Moving forward, we will only provide support the very latest version of Kirki.
Thank you for your understanding.
Best,
David


Integration Test - Release - 2021/11/02 06:35:04

Auto create for integration test. IssueCommandFlow

#pri1

Just type '#pri3'

#pri2

#pri3

#assign PRMergerTest1

#assign NonAllowedUser

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

#reassign PRMergerTest2

#please-close

#reassign NonAllowedUser

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

GitHub user PRMergerTest2 has been removed from the MicrosoftDocs organization, so they were automatically removed as an assignee.

#unassign PRMergerTest1

#unassign NonAllowedUser


Translations update from Hosted Weblate

Translations update from Hosted Weblate for Maccy/Settings / Pins.
Current translation status:

Hungarian and Latvian are merged in 1e87bffd23f7130b1f9b52a29994f85f3b954e2a and 4feaf5acf21596f23e8249cb749a15874e9b36da respectively. Other incomplete translations are going to be reset from the Weblate due to changes in the localization files location in Maccy 2.0.


chore(ci): Configure codecov patch job

Overview
Configures the codecov patch job to only run on pull requests.

#477  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @clabby and the rest of your teammates on  Graphite


Second part of fixes for pubid parsing

related #8

@ronaldtse regexps getting more complicates, any ideas on how to refactor / simplify them?

@ronaldtse regexps getting more complicates, any ideas on how to refactor / simplify them?

Regular expressions only work with simple data to a point. Which I think might still work in this case, but we really should use real parsing with components (and grammar).
Try https://github.com/kschiess/parslet ?

@mico FYI we have previously authored a report on the usage of NIST document identifiers: https://github.com/riboseinc/report-nist-pubid
Would be useful for you to review. Thanks.


data-vv-as dynamic translation is behind error message translation

Versions:

VueJs: 2.5.16
Vee-Validate: 2.0.6

Description:
There is necessity to translate attribute name. Vee provides two options to do that:

attributes. Using attributes is not useful when your app is big enough and there are many "name"s (or other similar business attributes) which have similar name but need to be localized using different labels. Changing business model properties to be able to specify different name is not useful.

data-vv-as allows you to specify attribute name. if you need translation you can translate it using vue-i18n module e.g.
:data-vv-as="$t('my.field.name')"

It works pretty well except one scenario when user sees error message on the page and decide to change language - in this case error message is changed correctly but attribute name remains from previous language. changing language again to another one shows previous translation which you expect before.  So it looks like data-vv-as evaluation is left behind error message itself.
Does it look like an issue in library or I missed something important.
Thanks in advanced.
Steps To Reproduce:

Well, messages are generated whenever a validation is triggered, and whenever the locale changes. If you are using the attributes binding it will lag behind since the data-vv-as has precedence over the dictionary and depending on the timing it may lag behind or not.
You can instead use the dictionary version in your i18n:
{
  en: {
    validation: {
      attributes: {
        myField: 'whatever'
      }
    }
  }
}

and your field name attribute would be:
name="myField"

Thank You


chore: release main

:robot: I have created a release beep boop
auto-instrumentations-node: 0.38.0
0.38.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-amqplib bumped from ^0.32.5 to ^0.33.0
@opentelemetry/instrumentation-aws-lambda bumped from ^0.35.3 to ^0.36.0
@opentelemetry/instrumentation-aws-sdk bumped from ^0.34.3 to ^0.35.0
@opentelemetry/instrumentation-bunyan bumped from ^0.31.4 to ^0.32.0
@opentelemetry/instrumentation-cassandra-driver bumped from ^0.32.4 to ^0.33.0
@opentelemetry/instrumentation-connect bumped from ^0.31.4 to ^0.32.0
@opentelemetry/instrumentation-dataloader bumped from ^0.4.3 to ^0.5.0
@opentelemetry/instrumentation-dns bumped from ^0.31.5 to ^0.32.0
@opentelemetry/instrumentation-express bumped from ^0.32.4 to ^0.33.0
@opentelemetry/instrumentation-fs bumped from ^0.7.4 to ^0.8.0
@opentelemetry/instrumentation-fastify bumped from ^0.31.4 to ^0.32.0
@opentelemetry/instrumentation-generic-pool bumped from ^0.31.4 to ^0.32.0
@opentelemetry/instrumentation-graphql bumped from ^0.34.3 to ^0.35.0
@opentelemetry/instrumentation-hapi bumped from ^0.31.4 to ^0.32.0
@opentelemetry/instrumentation-ioredis bumped from ^0.34.3 to ^0.35.0
@opentelemetry/instrumentation-knex bumped from ^0.31.4 to ^0.32.0
@opentelemetry/instrumentation-koa bumped from ^0.34.6 to ^0.35.0
@opentelemetry/instrumentation-lru-memoizer bumped from ^0.32.4 to ^0.33.0
@opentelemetry/instrumentation-memcached bumped from ^0.31.4 to ^0.32.0
@opentelemetry/instrumentation-mongodb bumped from ^0.35.0 to ^0.36.0
@opentelemetry/instrumentation-mongoose bumped from ^0.32.4 to ^0.33.0
@opentelemetry/instrumentation-mysql bumped from ^0.33.3 to ^0.34.0
@opentelemetry/instrumentation-mysql2 bumped from ^0.33.4 to ^0.34.0
@opentelemetry/instrumentation-nestjs-core bumped from ^0.32.5 to ^0.33.0
@opentelemetry/instrumentation-net bumped from ^0.31.4 to ^0.32.0
@opentelemetry/instrumentation-pg bumped from ^0.35.3 to ^0.36.0
@opentelemetry/instrumentation-pino bumped from ^0.33.4 to ^0.34.0
@opentelemetry/instrumentation-redis bumped from ^0.34.7 to ^0.35.0
@opentelemetry/instrumentation-redis-4 bumped from ^0.34.6 to ^0.35.0
@opentelemetry/instrumentation-restify bumped from ^0.32.4 to ^0.33.0
@opentelemetry/instrumentation-router bumped from ^0.32.4 to ^0.33.0
@opentelemetry/instrumentation-socket.io bumped from ^0.33.4 to ^0.34.0
@opentelemetry/instrumentation-tedious bumped from ^0.5.4 to ^0.6.0
@opentelemetry/instrumentation-winston bumped from ^0.31.4 to ^0.32.0
@opentelemetry/resource-detector-alibaba-cloud bumped from ^0.27.7 to ^0.28.0
@opentelemetry/resource-detector-aws bumped from ^1.2.5 to ^1.3.0
@opentelemetry/resource-detector-container bumped from ^0.2.5 to ^0.3.0
@opentelemetry/resource-detector-gcp bumped from ^0.28.3 to ^0.29.0

auto-instrumentations-web: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-document-load bumped from ^0.32.3 to ^0.33.0
@opentelemetry/instrumentation-user-interaction bumped from ^0.32.4 to ^0.33.0

contrib-test-utils: 0.34.0
0.34.0 (2023-07-12)
Features

add sqlcommenter comment to mysql2 queries (#1523) (856c252)
minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

host-metrics: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

id-generator-aws-xray: 1.2.0
1.2.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

instrumentation-amqplib: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-aws-lambda: 0.36.0
0.36.0 (2023-07-12)
Features

lambda: add OTEL_LAMBDA_DISABLE_AWS_CONTEXT_PROPAGATION environment variable (#1227) (8777cbd)
minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/propagator-aws-xray bumped from ^1.2.1 to ^1.3.0

instrumentation-aws-sdk: 0.35.0
0.35.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)
opentelemetry-instrumentation-aws-sdk: add missing spec-defined DynamoDB attributes (#1524) (f7c4324)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/propagation-utils bumped from ^0.29.5 to ^0.30.0

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-bunyan: 0.32.0
0.32.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-cassandra-driver: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-connect: 0.32.0
0.32.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

connect: Skip update HTTP's span name and update RpcMetadata's route instead (#1534) (8499b16)
deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-dataloader: 0.5.0
0.5.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-dns: 0.32.0
0.32.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-document-load: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)
opentelemetry-instrumentation-document-load: Add access to performance resource timing object for custom attributes (#1529) (7c7294c)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)
document-load: compatibility issue with<EMAIL_ADDRESS>(#1565) (774d254)

instrumentation-express: 0.33.0
0.33.0 (2023-07-12)
Features

express: Skip update HTTP's span name and update RpcMetadata's route instead (#1557) (8e2f518)
minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-fastify: 0.32.0
0.32.0 (2023-07-12)
Features

fastify: Skip update HTTP's span name and update RpcMetadata's route instead (#1569) (8d9687d)
minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)
instrumentation-fastify: fix fastify typescript compilation issue (#1556) (784a422)

instrumentation-fs: 0.8.0
0.8.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-generic-pool: 0.32.0
0.32.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-graphql: 0.35.0
0.35.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-hapi: 0.32.0
0.32.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-ioredis: 0.35.0
0.35.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/redis-common bumped from ^0.35.1 to ^0.36.0

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-knex: 0.32.0
0.32.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-koa: 0.35.0
0.35.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-long-task: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-lru-memoizer: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-memcached: 0.32.0
0.32.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-mongodb: 0.36.0
0.36.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)
mongodb: support v5 (#1451) (05c4e9e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-mongoose: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-mysql: 0.34.0
0.34.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-mysql2: 0.34.0
0.34.0 (2023-07-12)
Features

add sqlcommenter comment to mysql2 queries (#1523) (856c252)
minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0
@opentelemetry/sql-common bumped from ^0.39.0 to ^0.40.0

instrumentation-nestjs-core: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)
nestjs: update dependency @nestjs/x to v9 (#1538) (fec1799)

instrumentation-net: 0.32.0
0.32.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-pg: 0.36.0
0.36.0 (2023-07-12)
Features

add sqlcommenter comment to mysql2 queries (#1523) (856c252)
minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/sql-common bumped from ^0.39.0 to ^0.40.0

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-pino: 0.34.0
0.34.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-redis: 0.35.0
0.35.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/redis-common bumped from ^0.35.1 to ^0.36.0

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-redis-4: 0.35.0
0.35.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/redis-common bumped from ^0.35.1 to ^0.36.0

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-restify: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-router: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-socket.io: 0.34.0
0.34.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-tedious: 0.6.0
0.6.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

instrumentation-user-interaction: 0.33.0
0.33.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

instrumentation-winston: 0.32.0
0.32.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

plugin-react-load: 0.29.0
0.29.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

propagation-utils: 0.30.0
0.30.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

propagator-aws-xray: 1.3.0
1.3.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

propagator-grpc-census-binary: 0.27.0
0.27.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

propagator-instana: 0.3.0
0.3.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

propagator-ot-trace: 0.27.0
0.27.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

redis-common: 0.36.0
0.36.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

resource-detector-alibaba-cloud: 0.28.0
0.28.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

resource-detector-aws: 1.3.0
1.3.0 (2023-07-12)
Features

aws-ecs: add cloud resource attributes for fargate (#1543) (de17f77)
minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

resource-detector-container: 0.3.0
0.3.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

resource-detector-gcp: 0.29.0
0.29.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

resource-detector-github: 0.28.0
0.28.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

resource-detector-instana: 0.5.0
0.5.0 (2023-07-12)
Features

minification: Add importHelpers and tslib as a dependency (#1545) (65f612e)

Bug Fixes

deps: update otel core experimental to ^0.41.0 (#1566) (84a2377)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.33.4 to ^0.34.0

sql-common: 0.40.0
0.40.0 (2023-07-12)
Features

add sqlcommenter comment to mysql2 queries (#1523) (856c252)
upstream mocha instrumentation testing plugin from ext-js #621 (#669) (a5170c4)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-alibaba-cloud-v0.28.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-aws-v1.3.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-container-v0.3.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-gcp-v0.29.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-github-v0.28.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-instana-v0.5.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/auto-instrumentations-web-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/host-metrics-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/id-generator-aws-xray-v1.2.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagation-utils-v0.30.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/redis-common-v0.36.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/sql-common-v0.40.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/contrib-test-utils-v0.34.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-amqplib-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-dataloader-v0.5.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-fs-v0.8.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-lru-memoizer-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mongoose-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-socket.io-v0.34.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-tedious-v0.6.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-aws-lambda-v0.36.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-aws-sdk-v0.35.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-bunyan-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-cassandra-driver-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-connect-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-dns-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-generic-pool-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-hapi-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-ioredis-v0.35.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-knex-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-memcached-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mysql-v0.34.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mysql2-v0.34.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-nestjs-core-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-net-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-pg-v0.36.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-pino-v0.34.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-redis-v0.35.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-redis-4-v0.35.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-restify-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-router-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-winston-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-document-load-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-long-task-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-user-interaction-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/plugin-react-load-v0.29.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagator-aws-xray-v1.3.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagator-grpc-census-binary-v0.27.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagator-instana-v0.3.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagator-ot-trace-v0.27.0 :sunflower:


[portaudio] Add pa_win_waveformat.h to public includes

pa_win_wasapi.h includes pa_win_waveformat.h, so it has to be distributed for pa_win_wasapi.h to be usable.
This fixes the following error:
vcpkg\installed\x64-windows\include\pa_win_wasapi.h(47): fatal error C1083: Cannot open include file: 'pa_win_waveformat.h': No such file or directory

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: dechamps sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for the fix!


finalize kube lint

@AsfaMumtaz Image is available for testing. docker pull stakater/workshop-excercise:SNAPSHOT-PR-50-ce3464e2


added new question of Disjoint Set for hacktober fest 2022

added data for hacktober fest 2022

Don't Forget to star this repository!


Investigate alternative ways of exposing "Deploy" functionality to users

PT: 176175964

From Tracker:
Currently (Dec. 15) we're working on a button that will deploy a .NET project to TAS & the button that will trigger this process lives in the context menu (right-click menu) of a project in the VS Solution Explorer. Visual Studio users typically use the built-in "Publish" button from that same menu to deploy apps, so it'd be ideal if we could add a row to that "Publish" dialog that provides an option to push to TAS. Unfortunately our research hasn't turned up any methods for extending that "Publish" dialog.
Let's investigate how other extensions (e.g. from Google/AWS) expose "Deploy" functionality; are they able to hook into the "Publish" menu? Do they expose their own custom deploy buttons in project context menus? Do they provide "deploy" buttons elsewhere?

Closing for #118


Draft Testing Plan

What we should improve & how.
Submit as a markdown file against realm/realm-cocoa so others can review & improve

See also some previous ideas in #1695

This is too vague. Closing.


iroh-net: Persist peer information

To facilitate start-up operations it would be useful to have a set of known peers on start up.
There are a couple of questions surrounding this issue:

Where to store this information
What information to store
When to persist this information

Some thoughts about the relevant questions
1. Where to store the information
It was suggested to use the current db. Noting this here to confirm. I have not yet checked where do we start the db and how we interact with it
2. What information to store:
I was pointed to the PeerMap: https://github.com/n0-computer/iroh/blob/c6935bddbef652982d58145c7936cb9efb1023a3/iroh-net/src/magicsock/endpoint.rs#L1029-L1035
This is my understanding so far, let me know if anything is not correct:

The "id" (an usize) is a runtime-only id, as far as I can tell it's only ever used to manage pending pings. Since we have the following mappings:

by_node_key: {PublicKey -> Id}
by_id: {Id -> Endpoint}

from intuition and from this I would assume the real identifier is the PublicKey, I would thus not persist the "id".

These are the contents of an Endpoint: lots of interesting things here
https://github.com/n0-computer/iroh/blob/c6935bddbef652982d58145c7936cb9efb1023a3/iroh-net/src/magicsock/endpoint.rs#L51-L84

id: usize as mentioned above I would not persist this
conn_sender: mpsc::Sender<ActorMessage>: This seems to be a back reference to the actor holding the PeerMap. This can be filled by the actor on start up
quic_mapped_addr: QuicMappedAddr: this seems to be relevant only on runtime as it can be generated so I wouldn't consider this to be necessary to be persisted.
conn_public_key: PublicKey trying to get rid of this in #1482
public_key: PublicKey should be persisted
last_full_ping: Option<Instant> set to None
derp_region: Option<u16> persisted
best_addr: Option<AddrLatency> set to None?
best_addr_at: Option<Instant> set to None?
trust_best_addr_until: Option<Instant> set to None?
endpoint_state: HashMap<SendAddr, EndpointState> set to default()
is_call_me_maybe_ep: HashMap<SocketAddr, bool> set to default()
pending_cli_pings: Vec<PendingCliPing> set to default()
expired: bool more notes on this below
sent_ping: HashMap<stun::TransactionId, SentPing> set to default()
last_active: Instant we could store it, might be useful?

On expired
This is never set to true, so unused in reality. It's read in two places, one in a fn marked as allow_unused and in get_send_addrs to emit an error. So it seems there is some missing logic to either "refresh" endpoints or purge them? Based on this and looking at the code, PeerMap is only ever growing. So sadly this is mem leak that might be noticeable to well connected, long-running nodes.
In terms of persistence it would be good to find a way of prunning this so that the persisted version is not growing unbounded for short-lived nodes
3. When to persist this information
My proposal was to persist this in two occasions:

on shutdown. Here I noticed that when shutting down some values are reset https://github.com/n0-computer/iroh/blob/c6935bddbef652982d58145c7936cb9efb1023a3/iroh-net/src/magicsock/endpoint.rs#L628-L644 I find this interesting since this is not doing any memory freeing or io closing, so why do we do this? This updates metrics but it's only ever called on shutdown anyway. maybe this can be removed? in terms of persistence, none of the values that get reset to None are part of those I would persist anyway, or it's not clear to me why we would want to persist them.
When "enough" changes are seen, in a flush fashion, maybe akin to cow. Let's say persist once more than 10 relevant changes are seen. This makes sense in principle but it's hard to identify because the PeerMap allows mutable access to the Endpoint and there is no way to know if the Endpoint changed in a meaningful way (since so many values are not relevant for persistence). To do this, we would need to move mutability of the Endpoint to inside of the PeerMap. Not sure this is the way to go, so maybe the strategy persistence should be another one.


Sometimes won't react to touchpresses

VSCode Version: 0.10.11
OS Version: Windows 10 10586.164
Surface Pro 4

Steps to Reproduce:

Install Code
Attempt to press anything using only a touchscreen.

I'm not entirely sure how to reproduce it. I downloaded Code yesterday to learn Typescript, and none of the buttons worked when I tried to use the touch screen, but worked if I used the touchpad or pen. I uninstalled it, because that's a dealbreaker, tried Visual Studio, but found it to be a little complicated just to mess around in, so I decided, what the hell, and re-installed Code. It now works fine.

@carcigenicate This sounds like you might have hit a problem that went aways after a restart.
If you encounter this problem again, we would love to get some steps on how to reproduce.

Closing after a number of days without a response.


include failure exporter check in e2e

two switches here

intent to test failure exporter
GITHUB_SECRET or in future JIRA_SECRET

either or both can be used

invoked w/
./scripts/run-pelorus-e2e-tests -o konveyor -e failure

once 4.10 passes w/ updates, this call will change in the
makefile

Describe the behavior changes introduced in this PR
Linked Issues?
https://github.com/openshift/release/pull/29693
resolves # <-- Use this if merging should auto-close an issue
related to # <-- Use this if it shouldn't
Testing Instructions
Please include any additional commands or pointers in addition to our standard PR testing process.
@redhat-cop/mdt

/hold
Something went wrong while testing script on a local box (attached output from run)
e2e.txt

/hold
Something went wrong while testing script on a local box (attached output from run) e2e.txt

@mpryc looks like mongo didn't pull or start. I've seen that happen once before.  That is all in the mongo-persistent.yaml template not 100% what to do about that tbh

test all

seems good to me.
https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/konveyor_pelorus/512/pull-ci-konveyor-pelorus-master-4.8-e2e-openshift/1539348168125190144/artifacts/e2e-openshift/e2e/build-log.txt


tweepy error, code 215

Hi guys! I have been trying to make the example script work. Installed all the dependencies, got the all the keys and stuff. Here is the error I am getting:
Traceback (most recent call last):
  File "twitter_bot.py", line 13, in <module>
    result = bom.check_account('@clayadavis')
  File "/Users/aabhishek/anaconda/lib/python2.7/site-packages/botometer/__init__.py", line 113, in check_account
    full_user_object=full_user_object)
  File "/Users/aabhishek/anaconda/lib/python2.7/site-packages/botometer/__init__.py", line 67, in _get_twitter_data
    user_timeline = self.twitter_api.user_timeline(user, count=200)
  File "/Users/aabhishek/anaconda/lib/python2.7/site-packages/tweepy/binder.py", line 245, in _call
    return method.execute()
  File "/Users/aabhishek/anaconda/lib/python2.7/site-packages/tweepy/binder.py", line 229, in execute
    raise TweepError(error_msg, resp, api_code=api_error_code)
tweepy.error.TweepError: [{u'message': u'Bad Authentication data.', u'code': 215}]

Any help will be appreciated!

Authentication with Twitter and with Mashape, and since the error you're seeing is a tweepy TweepError, it means that there's an issue with your Twitter authentication. Did you fill in your Twitter API keys?

Yes, I used the same keys to run a simple tweet-streaming script to be sure that my keys work fine (and they do). I got my mashup keys from the Mashup Market, as shown in the instructions. I am guessing I should not be posting my script with all the keys here?

Posting your keys is probably not a good idea. The error is clearly with the Twitter authentication (via Tweepy), not Mashape. It might be something as simple as having the key names mixed up?
One thing you can try: after creating your Botometer instance, e.g. bom = botometer.Botometer(...), check out the bom.twitter_api property. This exposes the Tweepy API object, and you could try something like bom.twitter_api.verify_credentials() in order to get information about the authenticated user.

 Thanks for all the help!

Great to hear. Added this to the Troubleshooting guide in the wiki.


Inconsistent Behavior Between Wikilinks and Backlinks

Please select the area your Bug applys to. (Multiple selections are Possible)

[ ] Onboard. Initial vault setup and import/export pods
[ ] Create. Note creation, lookup, snippets and templates
[X] Retrieve. Backlinks, references, graph view
[ ] Structure. Refactoring, multi-vault and schemas
[ ] Publish. Sharing your repo with the world
[ ] Misc (Choose this if your not sure)

Describe the bug
The behavior between wikilinks and backlinks is inconsistent for note titles in regards to capitalization.
If a note (example.md) is linked to with the title capitalized ([[Example]]), hovering over the link will bring up the preview, and CTRL clicking will open the note. Both results indicate that the wikilink is recognized and that wikilinks are case insensitive.
However, on the note itself, the link will not be recognized in the backlinks panel. To get the link to show up in the backlinks panel, the link must be edited to be case sensitive (either [[example]] or [[Example|example]]).
This behavior extends to longer titles: for example.test.trial.md, the wikilink [[Example.Test.Trial]] will work, but will not be recorded in the backlinks panel unless the capitalization is modified.
To Reproduce
Steps to reproduce the behavior:

Create a note, "example.md".
Create a link to the new note on another note with the title capitalized, [[Example]].
Hovering over the link will bring up the preview of example.md, and the link can be used to open the note.
Returning to example.md however, no backlink will be recognized.
Return to the link and edit the capitalization (either [[example]] or [[Example|example]]).
The backlink will now be recognized.

Expected behavior
That wikilinks and backlinks behave the same, with both case sensitive, or both case insensitive.
Desktop (please complete the following information)

OS: Windows 10
Browser: NA
Version: Dendron 0.47.0

Additional context
In writing, titles are capitalized, but file-naming conventions encourage all lowercase. This is less of an issue with longer titles (the above "example.test.trial.md" would probably be linked as follows: [[example.test.trial|Trial]]), but for one word titles, it is very easy for a user to think they have created a working link ([[Example]]) without realizing that it will not be recorded in the backlinks panel.
Thank you.

@all-contributors please add @micharris42 for bug. Good catch!

This should be fixed in v0.70 of Dendron. Please post here if not, otherwise this issue will auto close in 4 days

@Harshita-mindfire
Hi!
I checked this issue.
My problem solved! Backlinks in v0.70.0 now is worked.
Many thanks!

Seconded. Backlinks are being recognized regardless of capitalization.
Marking as Closed.


feat(deployment): set default replica count to 2 (#1138)

Backport
This will backport the following commits from k8s-24/main to k8s-22/main:

feat(deployment): set default replica count to 2 (#1138)

Questions ?
Please refer to the Backport tool documentation

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1164

Questions ?
Please refer to the Backport tool documentation


NPE for non-existent function in web adapter

Create a function with spring-cloud-starter-function-webflux and use FunctionalSpringApplication. Run it. POST to /non-existent. Instead of a 404 you get a 500:
2019-07-09 13:32:49.401 ERROR 32199 --- [or-http-epoll-2] a.w.r.e.AbstractErrorWebExceptionHandler : [8d54095a] 500 Server Error for HTTP POST "/registration_com.example.functions.Greeter"

java.lang.NullPointerException: null
	at org.springframework.cloud.function.web.RequestProcessor.response(RequestProcessor.java:243) ~[classes/:na]
	at org.springframework.cloud.function.web.RequestProcessor.post(RequestProcessor.java:156) ~[classes/:na]
	at org.springframework.cloud.function.web.function.FunctionEndpointFactory.lambda$null$0(FunctionEndpointInitializer.java:235) ~[classes/:na]
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:118) ~[reactor-core-3.2.8.RELEASE.jar:3.2.8.RELEASE]
...

I don't know if this is a problem with a regular @SpringBootApplication, or if it is a problem with MVC. Probably same code path though.

It appears to be not just webflux but any non-existent function. I was able to easily reproduce it


Json & HTML report are not generated

Current behavior
Upon execution, JSON & HTML report are not generated. Followed the same process as described in the documentation.
Desired behavior
Json & HTML report should be generated when executed
Test code to reproduce
Sample Replicable repo: https://github.com/sadhishsk/Cypress-cucumber-bdd/tree/main
Versions

Cypress version: 13.7.3
Preprocessor version: 20.0.3
Node version: 20.12.2

Checklist

[x] I've read the FAQ.
[x] I've read instructions for logging issues.
[x] I'm not using<EMAIL_ADDRESS>(package name has changed and it is no longer the most recent version, see #689).

https://github.com/badeball/cypress-cucumber-preprocessor/blob/master/docs/faq.md#json-reports-arent-generated-in-open--interactive-mode

@badeball I tried it in run mode but still JSON and HTML aren't generated!

omitAfterRunHandler: true
...
afterSpecHandler(config, spec, results);
.. I expect you to see the error here.


Embed signups directly on homepage

Currently, it's at /action, but potentially losing hundreds of possible signups due to UI/UX. Homepage might help solve this issue.

@rickr, looks like this has been resolved. Closing.


Broken link for Docker Airflow Spark example

Describe the issue
In the README file there is a broken link: https://github.com/nanlabs/devops-reference/tree/main/examples/compose-airflow/
I believe that the correct one is: https://github.com/nanlabs/devops-reference/tree/main/examples/compose-airflow-spark
Links
https://github.com/nanlabs/awesome-nan/blob/main/README.md

@jalessandro thanks for opening the issue! I fixed it on both, awesome-nan and devops-reference!
https://github.com/nanlabs/devops-reference/commit/e51fb8b48ad4e6e07d55f1605f896994f5046ebf


dask.distributed Client freezes after recent software upgrade.

After a recent forced upgrade, nothing that uses dask.distributed now freezes and refuses to work.  I am able to replicate this with the following code from pangeo/notebooks/newmann_ensemble_meteorology.ipynb

from dask.distributed import Client
client = Client(scheduler_file='/glade/scratch/jhamman/scheduler.json')
client
I notice that I get messages:
Adapting to protocol v5.1 for kernel 48f87baf-4f25-418a-9eb1-cd7ed4d7fc91

and following the net I have tried installing ipykernel  jupyter_client ipyparallel, and changing my port from 8888 to 8889 and 9012.  I have also tried re-initializing jupyer_notebook_config.py, rebooting the machine, and I cannot remember what all.  Has there been a recent change (since 4.4, or maybe I had 5.0 installed, still trying to figure that out).  Anyway, this morning everything worked fine until I installed pangeo and xarray.  Now dask.distributed is broken.
Any suggestions?
I should also note that after everything went sideways I moved my old install to the side and did a full clean install from the most recent anaconda version.  So I am currently working from a clean pangeo environment.yml install.

Issue moved to dask/distributed #1867 via ZenHub


Docker-compose up error

Package version (if known): v1.0.0a42
Describe the bug
When running docker-compose -f docker-compose.full.yml up, I get this error:
  Building wheel for infinity (setup.py): started
  Building wheel for infinity (setup.py): finished with status 'done'
  Created wheel for infinity: filename=infinity-1.5-py3-none-any.whl size=3081 sha256=93adf3c03202315ef33c064945208904b5aa43dbc20e393420388c44f42c1f02
  Stored in directory: /root/.cache/pip/wheels/ed/29/a2/e785f7122ae93aef04e0616e7748ac397ec80d6ea432afbff3
Successfully built pycountry blinker ftfy click-default-group fs SQLAlchemy-Utils Flask-Login maxminddb-geolite2 python-geoip pytest-pycodestyle pytest-pydocstyle click-didyoumean SQLAlchemy-Continuum flask-limiter Flask-Mail WTForms-Alchemy future Flask-KVSession-Invenio jsmin Flask-Admin Flask-Principal node-semver pyrsistent maxminddb alembic limits speaklater infinity
Installing collected packages: six, ipython-genutils, decorator, traitlets, wcwidth, prompt-toolkit, parso, jedi, Pygments, backcall, ptyprocess, pexpect, pickleshare, IPython, click, MarkupSafe, Jinja2, itsdangerous, Werkzeug, Flask, flask-shell-ipython, blinker, invenio-base, Flask-Caching, invenio-cache, invenio-config, flask-talisman, pytz, billiard, click-didyoumean, vine, click-repl, zipp, typing-extensions, importlib-metadata, amqp, kombu, click-plugins, pytest-celery, celery, Flask-CeleryExt, uritools, limits, flask-limiter, invenio-app, msgpack, redis, invenio-celery, speaklater, babel, Flask-BabelEx, invenio-i18n, dnspython, idna, email-validator, node-semver, pynpm, pywebpack, Flask-WebpackExt, Flask-Collect, invenio-assets, Flask-Menu, Flask-Breadcrumbs, jsmin, invenio-theme, simplekv, Flask-Login, WTForms, Flask-WTF, Flask-CORS, marshmallow, webargs, invenio-rest, ua-parser, pycparser, cffi, cryptography, maxminddb, maxminddb-geolite2, Flask-KVSession-Invenio, Flask-Mail, pyjwt, Flask-Principal, passlib, Flask-Security, future, invenio-accounts, invenio-userprofiles, oauthlib, urllib3, chardet, certifi, requests, requests-oauthlib, invenio-mail, cachelib, Flask-OAuthlib, invenio-oauthclient, Flask-Admin, SQLAlchemy, Flask-SQLAlchemy, SQLAlchemy-Utils, Mako, python-editor, python-dateutil, alembic, Flask-Alembic, psycopg2-binary, SQLAlchemy-Continuum, invenio-db, invenio-admin, invenio-access, validators, infinity, intervals, WTForms-Components, WTForms-Alchemy, invenio-oauth2server, invenio-logging, pyparsing, packaging, webencodings, bleach, arrow, invenio-formatter, invenio, base32-lib, invenio-pidstore, jsonpointer, jsonpatch, jsonref, pyrsistent, attrs, jsonschema, pluggy, jsonresolver, invenio-records, invenio-indexer, invenio-jsonschemas, lxml, simplejson, dojson, invenio-oaiserver, ftfy, invenio-records-rest, click-default-group, fs, invenio-files-rest, invenio-banners, invenio-circulation, invenio-opendefinition, invenio-pages, invenio-pidrelations, python-geoip, counter-robots, invenio-queues, invenio-stats, Flask-Debugtoolbar, pycountry, sphinxcontrib-htmlhelp, snowballstemmer, sphinxcontrib-devhelp, sphinxcontrib-serializinghtml, imagesize, alabaster, sphinxcontrib-jsmath, sphinxcontrib-qthelp, docutils, sphinxcontrib-applehelp, Sphinx, lorem, mock, iniconfig, toml, py, pytest, pep517, build, check-manifest, pytest-flask, isort, pytest-isort, coverage, pytest-cov, docker-services-cli, pycodestyle, pytest-pycodestyle, pydocstyle, pytest-pydocstyle, selenium, pytest-invenio, pytest-mock, elasticsearch, elasticsearch-dsl, invenio-search, invenio-app-ils
  Running setup.py develop for invenio-app-ils
ERROR: pip's legacy dependency resolver does not consider dependency conflicts when selecting packages. This behaviour is the source of the following dependency conflicts.
flask 1.1.4 requires click<8.0,>=5.1, but you'll have click 8.0.0 which is incompatible.
flask 1.1.4 requires itsdangerous<2.0,>=0.24, but you'll have itsdangerous 2.0.1 which is incompatible.
celery 5.0.5 requires click<8.0,>=7.0, but you'll have click 8.0.0 which is incompatible.
docker-services-cli 0.3.0 requires click<8.0,>=7.0, but you'll have click 8.0.0 which is incompatible.
 You should install packages reliably by using venv: https://pip.pypa.io/warnings/venv
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 568, in _build_master
    ws.require(__requires__)
  File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 886, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 777, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (click 8.0.0 (/usr/local/lib/python3.6/site-packages), Requirement.parse('click<8.0,>=5.1'), {'Flask'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/ils", line 33, in <module>
    sys.exit(load_entry_point('invenio-app-ils', 'console_scripts', 'ils')())
  File "/usr/local/bin/ils", line 25, in importlib_load_entry_point
    return next(matches).load()
  File "/usr/local/lib/python3.6/site-packages/importlib_metadata/__init__.py", line 166, in load
    module = import_module(match.group('module'))
  File "/usr/local/lib/python3.6/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 941, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/usr/local/lib/python3.6/site-packages/invenio_app/__init__.py", line 172, in <module>
    from .ext import InvenioApp
  File "/usr/local/lib/python3.6/site-packages/invenio_app/ext.py", line 15, in <module>
    import pkg_resources
  File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3242, in <module>
    @_call_aside
  File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3226, in _call_aside
    f(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3255, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 570, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 583, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 777, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (click 8.0.0 (/usr/local/lib/python3.6/site-packages), Requirement.parse('click<8.0,>=5.1'), {'Flask'})

Steps to Reproduce

git clone https://github.com/inveniosoftware/invenio-app-ils invenioils
cd invenioils
docker-compose -f docker-compose.full.yml up

See error

Additional context
I simply tried to run preview on my Debian 10 buster freshly-installed Linux OS.

i have this problem too
seems like it was the click version dependency problem that installed when the setup is running, the error said we need click <8.0.0 for flask etc.

same issue, any workaround?


Improve the interactive console

Improve the interactive console with keybindings,history,completion

Thanks, it's amazing! I test it with Windows Terminal / VS Code terminal on both Windows and WSL, but the auto-completion does not seem to work for all of them:

When pressing TAB while no text is pending, all possible commands show up as expected but cannot be selected.
When pressing TAB while some text is pending, the completion does not work at all.

Could you please find some way to fix it? I'm excited to add these functions to this project!

Doesn't it work like this ?

I try the program again on another terminal software and it works fine, just like your screenshot. Maybe it's just a compatibility issue with the readline library.