Grafana - Athena datasource access key rotation fails

What happened:
Our workflow was next:

We've created an IAM user + access key
Used this access key in Athena datasource. The datasource and Grafana dashboard started to work as expected
We've tried to update an access key: deleted an old one, generated a new one and updated with this new access key Athena datasource
After that immediately we got an error: "error querying the database: error executing query: UnrecognizedClientException: The security token included in the request is invalid. status code: 400, request id: 72b289e4-1eb5-4e57-a502-59930882c1fe"

What you expected to happen:
Grafana should continue to work without any issues after a new access key was applied.
How to reproduce it (as minimally and precisely as possible):

Screenshots

Anything else we need to know?:
Environment:

Grafana version: 9.3.1
Plugin version: latest
OS Grafana is installed on: on premise
User OS & Browser: Mac OS, Chrome
Others:

I've found something similar here: https://github.com/grafana/grafana/pull/52420

Hi @MaxZorko I think this might have been fixed along with this ticket: https://github.com/grafana/athena-datasource/issues/246
Can you update your datasource and check if that did it? Thanks!

We see the same issue - in practice we’ve found it necessary to delete and recreate the data source entirely, as if the info is cached - this would be nice to get fixed

Hi @MaxZorko @MatinF ! Sorry to hear you're still having issues. I investigated this and I was able to reproduce it. I'll add it to our next column to be picked up when we can.
For whoever picks this up:
From what I can tell, while the other PR fixed how the api's are cached (so the resource handlers, which get the API every time, get the new credentials successfully), it seems like the queries never fetch the api/session after the first query is called for the Athena datasource. This supported by the fact that the new credentials work if the grafana server is restarted.
Also a note for reproing: it takes AWS a little time to kill an access key so wait for it to fail before saving a new one.

This will be addressed by https://github.com/grafana/sqlds/pull/111 and https://github.com/grafana/grafana-aws-sdk/pull/128. Once those are released we'll bump the versions here.


[sched, alarm] allow dated Event repeat

Dated Events can now be repeated every X number of days, weeks, months or years. (eventually we'd add a new "until" param, but I won't do that until we have a date picker)
e.g. to repeat the Event every 2 months, sched.json would have an entry with:
rp : { interval: "month", num: 2 }

Cool, I wonder how do you add the dates, do you use gadgetbridge for that? Do we need some kind of ics uploader in the webinterface?

Currently, the Alarm app allows to input dates for the new "Event" alarm type.  Sched already supported dates, but not date repeats - the new part in this PR.  The current idea is to have a Standalone way to manage alarm + title + date, but I'm sure there would be a way to use the same with gadgetbridge, if it's not already done in another app (but your phone may have more "repeat" options than the ones added here, so you'd have to manage compatibility or expand the available repeat types in sched).

@gfwilliams I wonder, what is the reason why this PR is not approved?

This came in alongside a bunch of other work, and since it touched the internals of sched which have historically caused a bit of trouble, I wanted some time to check it out properly.
I've just taken a look, and I'm a bit concerned about what happens for existing alarms with dates (I think they will maybe just end up getting left on and set to the same day), so I might have to make some changes for that before merging.


[themeadapter-material] Fix typo in  themeadapter-material.md

Thanks for this, you'll just need to follow the instructions above to fill out a license agreement before I can merge it.

Thanks for this, you'll just need to follow the instructions above to fill out a license agreement before I can merge it.

Already signed the CLA


Suggestion: More adaptable replication config

I am very happy with this ldap-container, but want to do provider-consumer replication.
Currently, this is not possible, as the replication either does setup multi-master-replication with LDAP_REPLICATION=true, or deletes all syncprov config AFTER loading the custom bootstrap ldifs, preventing me to just setup my own replication via bootstrap ldifs.
I suggest a usage of LDAP_REPLICATION="own", which skips the disable_replication in https://github.com/osixia/docker-openldap/blob/stable/image/service/slapd/startup.sh#L488
What do you think of this, or do you know of an other way to use all of the other replication methods openldap provides?

My current workaround is to mount an empty file on top of /container/service/slapd/assets/config/replication/replication-disable.ldif, so that disable-replication doesn't do anything...


big.js vs. bignumber.js vs. decimal.js?

Suggestion: describe in the readme how these three libraries differ. AFAICT, big.js only supports base 10, whereas bignumber.js supports arbitrary bases. But what distinguishes decimal.js from big.js?

Ah! I found a good explanation in the repository for decimal.js. Still, a cheat sheet explaining which of the three libraries are best used in which situation may make sense.

There's also #2 , but yes I take your point. I need to set the differences down in one place that I can then link to from each repository. I'll address the matter soon. Thanks for the feedback.

You’re welcome. It’s been a joy working with decimal.js (good docs, simply install via npm, etc.).

@rauschma Where did you find the comparison document. I can't see it. I had the same question.

@PilotBob
In short:
big.js: minimalist; easy-to-use; precision specified in decimal places; precision applied to division only.
bignumber.js: bases 2-64; configuration options; NaN; Infinity; precision specified in decimal places; precision applied to division only; base prefixes.
decimal.js:  bases 2-64; configuration options; NaN; Infinity; non-integer powers, exp, ln, log; precision specified in significant digits; precision always applied; random numbers.
At length:
big.js is a minimalist arbitrary-precision library. It is the simplest and smallest of the three, less than half the size of bignumber.js and with only half the number of methods. It doesn't accept NaN or Infinity as legitimate values, it doesn't work with numbers of other bases, and the only runtime configuration available is the ability to set the number of decimal places and rounding mode of operations involving division.
Big.DP = 7;
Big.RM = 4;             // round half-up
var x = new Big(5);
x.div(3).toString();    // '1.6666667'

Like the other two libraries, it includes toExponential, toFixed and toPrecision methods. Unlike the others, it stores values in base 10 which makes it easy to change the properties of a Big directly if required
var x = new Big('123.456');
x.c;             // [1, 2, 3, 4, 5, 6] (coefficient, i.e. significand/mantissa)
x.e;             // 2 (exponent)
x.s;             // 1 (sign)
x.e = -3;
x.toString();    // '0.00123456'

bignumber.js and decimal.js store values in a higher base than big.js so they will be faster when performing operations on values with a large number of digits. They also support NaN and Infinity and can work with values in other bases (2 to 64 inclusive).
var x = new BigNumber('ff.8', 16);
x.toString();      // '255.5'
x.toString(16);    // 'ff.8'

bignumber.js and decimal.js also have various runtime configuration options, such as the ability to set the exponent value at which toString produces exponential notation.
var x = new Decimal(987654321);
x.toString();    // '987654321'
Decimal.config({ toExpPos: 4 });
x.toString();    // '9.87654321e+8'

decimal.js was orginally intended to be version two of bignumber.js but I decided to make them separate libraries. The main difference between them is that with decimal.js precision is specified in terms of significant digits instead of decimal places, and all calculations are rounded to the precision (similar to Python's decimal module) rather than just those involving division.
Bignumber.config({ DECIMAL_PLACES: 3, ROUNDING_MODE; 1 });
var x = new BigNumber('123.456789');
x.plus(1).toString();    // '124.456789'

Decimal.config({ precision: 7, rounding: 4 });
var y = new Decimal('123.456789');
y.plus(1).toString();    // '124.4568'

This could be considered to make bignumber.js easier to use than decimal.js, and perhaps more suitable for financial applications, because the user doesn't need to worry about losing precision unless an operation involving division is used.
Conversely, decimal.js may be considered better for more scientifc applications as it can handle very small or large values more efficiently: for example, it does not have the limitation of binumber.js that if adding a BigNumber value with a small exponent to one with a large exponent, bignumber.js will attempt to perform the operation to full precision which may involve the creation of a massive array, and consequently cause the operation to hang.
decimal.js also adds exp, ln, log and random functions, among others, and supports non-integer powers, which bignumber.js does not. These additions make decimal.js significantly larger than bignumber.js.
One thing that bignumber.js has that decimal.js currently does not, is support for binary, octal and hexadecimal prefixes
var x = new BigNumber('0b1101');
x.toString()    // '13'

Excellent information. Thanks.

@PilotBob
@PilotBob
Yes, and yes.
Perhaps I should have written "rounding" not "precision". I'm going to change it above.

Added the above description of the differences between the libraries to the Wiki, and a link to it from the README.

In short:
big.js: minimalist; easy-to-use; precision specified in decimal places; precision applied to division only.
bignumber.js: bases 2-64; configuration options; NaN; Infinity; precision specified in decimal places; precision applied to division only; base prefixes.
decimal.js: bases 2-64; configuration options; NaN; Infinity; non-integer powers, exp, ln, log; precision specified in significant digits; precision always applied; random numbers.

So if I understand this correctly, neither of the libraries allows for precision to be specified in decimal places and always be applied?
That's the one combination I need for financial calculations.

@adamreisnz
To round to decimal places:
big.js
x = new Big(123.456)
x = x.plus(0.78).round(2)

bignumber.js
x = new BigNumber(123.456)
x = x.plus(0.78).decimalPlaces(2)

Please don't make further comments in this thread.

The description https://github.com/MikeMcl/big.js/issues/45#issuecomment-104211175 is not in the docs any more? http://mikemcl.github.io/big.js

@ackvf
The link is there in the README on the second line under the title.


Dialogue balloon panel rendering scene (or sprites) inside itself

Describe the bug
The dialogue balloon is rendering a sprite that I have inside the same scene. (I can see the sprite in the background, and once the balloon appears, it renders inside of that as well). Debug printing inside of the sprite seems that it only loads once.
Affected version

Dialogue Manager version:
v2.41.3
Godot version:
4.2

To Reproduce
Steps to reproduce the behavior:
(Basically straight out of the tutorial)

Create a scene with a Node2D
Attach one child - a Sprite2D and add a resource
Add a script to the root node, the sprite, or to another node2d as a child
Create the balloon programmatically inside _unhandled_input (e.g. DialogueManager.show_dialogue_balloon(dialogue_resource, "start")
Add a custom balloon via project -> tools -> create copy of dialogue example balloon..
Click on Balloon.tscn -> Balloon control node -> open the theme
In the default preview, change type to panel and select the StyleBoxFlat theme
Reduce opacity
Run and notice sprite has rendered into the panel

Expected behavior
Not to have a sprite rendered inside the panel, not sure if I've missed some kind of vital step but I made a whole project from scratch with just these steps to check and had the same issue. It does this with all sprites I add to the scene.
Screenshots

I've had the same thing with the Vulkan mobile renderer due to this Godot bug.
Since the Panel for the example balloon is also using Clip + Draw, it will trigger this behavior for Godot 4. This seems to have been resolved for Godot 4.3. Meanwhile, changing the renderer to Forward+ solves the issue for current 4.X :)

Closing this as it's not technically a bug in Dialogue Manager itself.

I've had the same thing with the Vulkan mobile renderer due to this Godot bug.
Since the Panel for the example balloon is also using Clip + Draw, it will trigger this behavior for Godot 4. This seems to have been resolved for Godot 4.3. Meanwhile, changing the renderer to Forward+ solves the issue for current 4.X :)

Thankyou for this, you're amazing!


Required field and click enter mobile chrome

I liked the script, but I noticed some errors when implementing

Not working required, I saw the commit https://github.com/lekoala/bootstrap5-tags/commit/1447a5566b5617b968906dccc58259c1c3f8fa35
Adding this attribute does not display information about what is required

In the mobile version of chrome android, inserting a tag by clicking on enter does not work
Although you wrote that you fixed https://github.com/lekoala/bootstrap5-tags/releases/tag/1.4.17 I looked at the demo page

If you start writing text in the input field, then select it with the mouse and continue writing (rewriting the text), then the text is not written, the first time this error is reproduced immediately

When you click on the [label for="id"] or when clicking on the field the highlight is not activated like on classes (blue frame)
respectively, it is not possible to apply classes is-valid is-invalid

You didn’t think maybe implementing NOT through a [select] could solve most of the problems
as an example here https://bootstrap-tagsinput.github.io/bootstrap-tagsinput/examples/

@visavi hey thanks for your feedback
i'll check these issues if you find solutions in the meantime let me know
using a select itself should not be a major issue (and I do want to keep the basic features working with js disabled) but looking back at how i did things, i would certainly do it otherwise now :-) maybe that's for the v2

@visavi not sure i get what you mean by 1. => required only triggers on submit. please try to submit and you will see it's updated properly (it does on the demo)

@visavi regarding 3. => rewriting is not supported. if you select something, it is a set value.

@visavi you can give a try at https://github.com/lekoala/bootstrap5-tags/releases/tag/1.4.40 and tell me what you think

@lekoala 1. The "required" field works, but does not display a hint, that is, it is not clear that you need to enter data

before that, I tested with android on the demo page there and then and now there was a problem, the enter key did not work
now I have installed the new version 1.4.40 and also the previous one
It turns out that everything worked fine on the previous one, apparently the demo version is not updated

But on 1.4.40 now there is a problem, if you write the word Hello, then each letter will be like a tag

ok, it's not critical, you can work with it

In this version, when you click on the label, the focus is placed on the field, everything is ok, but there is no visual effect, blue highlight around the field
It's not really critical either.

@visavi mhh indeed this mobile android thing is tricky. i reverted the change and added a workaround to get the proper keycode. it seems that enter is supported by default but still that can be helpful
indeed, i missed the focus support. it's not easy since we need to have a :focus on the form-control. I added a class that can help with it but you need to implement it yourself (see .scss file)
otherwise, regarding the required hint, that's not expected to be(as it is the case in bootstrap). it's up to you to do it in css with after pseudo selector for example
https://github.com/lekoala/bootstrap5-tags/releases/tag/1.4.41
this hopefully should solve issues

@lekoala Everything works fine, everything is fine with focus too
Regarding the required field, apparently it will not be possible to solve the problem in the current version

Regarding the required field, apparently it will not be possible to solve the problem in the current version

what do you mean ? while it's not built in, it's easy to add with css but it all depends on how you want it to look :-) if you have an example that would help

Can you please tell me if it is possible to insert a tag on click outside the field?

@visavi sure, that should be possible. listen to blur and use getInstance then call addItem

I mean, if I started writing a word in the input field, and then without pressing enter I clicked outside the field
It would be nice if there was such a setting.

@visavi i see
i added two ways of doing this: a native setting (add-on-blur, see readme) and an event you can use if you have any specific business logic (see demo.html)
https://github.com/lekoala/bootstrap5-tags/releases/tag/1.4.42

@lekoala Everything works great, thanks


Allow base<5

Hi, I would like to use your library on GHC 7.10. I believe this is all that is required.

I'm not the author, I've been maintaining this library since it was used in our code. I made it to work with ghc 7.10rc1 or rc2 but later we came to a conclusion that this library is not required since exactly the same MaybeT implementation is included into transformers package.

(that was me btw)

@pacak @manpacket  Oh, yeah, you're right :)
I just s/Control.Monad.Maybe/Control.Monad.Trans.Maybe/ and all is well.


[BUG FIX]lose console log at rare time

Sometimes log4go will lose some log when called .Close() method. The error might be here.

Unfortunately, this is unmaintained.


Add a new pdfjs.enablePermissions preference, off by default, to allow the PDF documents to disable copying in the viewer (bug 792816)

Recently I've been looking through some older issues/bugs, to see if there's any ones that are now easy to address; this is a simple one that I found.

Please note: Most of the necessary API work was done in PR #10033, and the only remaining thing to do here was to implement it in the viewer.
The new preference should thus allow e.g. enterprise users to disable copying in the viewer, for PDF documents whose permissions specify that.
In order to simplify things the "copy"-permission was implemented using CSS, as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=792816#c55, which should hopefully suffice.[1]
The advantage of this approach, as opposed to e.g. disabling the textLayer completely, is first of all that it ensures that searching still works correctly even in copy-protected documents. Secondly this also greatly simplifies the overall implementation, since it doesn't require a lot of code for something that's disabled by default.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=792816 (assuming we care to do so).
/cc @brendandahl

[1] As the discussion in the bug shows, this kind of copy-protection is not very strong and is also generally easy to remove/circumvent in various ways. Hence a simple solution, targeting "regular"-users rather than "power"-users is hopefully deemed acceptable here.

/botio-linux preview

Was 10003 already merged into Firefox?

Was 10003 already merged into Firefox?

Yes, it landed all the way back in Firefox 64 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1488420); assuming that you meant #10033 of course :-)

Great. As soon as this lands in Firefox, I'll create an enterprise policy to enable.


Change transaction struct [Change inputs output to list]

And add is_cleanly_assigned into res struct

Can you please paste a before and after sample in the comment above please?

If something has is_cleanly_assigned=false and it's NOT burned. because they just got merged, then will is_burned be correctly still set to false?

I found a bug in #150
Before this, I had been using a dictionary in the code for transaction detail to return the index of a certain input or output. However, I overlooked one thing, which is that NFTs/FTs can actually be merged in the same single UTXO. So, there is a need to modify the structure to make a single UTXO contain multiple atomicals of assets. Therefore, the structure of the interface's return is modified to a list.
And here are some examples, after code fix, struct change:
Merge FTs, txid: dbe6c961e1182fd0f6704ad1d592952db77b841e64c788662f25b7d57882cc3e
{
  "success": true,
  "response": {
    "op": "transfer",
    "txid": "dbe6c961e1182fd0f6704ad1d592952db77b841e64c788662f25b7d57882cc3e",
    "height": 824642,
    "tx_num": 948609236,
    "info": {},
    "transfers": {
      "inputs": {
        "4": [
          {
            "address": "bc1q0c5aru88dtcq86ahnv09k392wnkdawkmzkxnav",
            "atomical_id": "9ba68637ba32edb6370bebceaac3df4341180cbf7bac210741b12a679692d716i0",
            "type": "FT",
            "index": 4,
            "value": 600
          },
          {
            "address": "bc1q0c5aru88dtcq86ahnv09k392wnkdawkmzkxnav",
            "atomical_id": "56a8702bab3d2405eb9a356fd0725ca112a93a8efd1ecca06c6085e7278f0341i0",
            "type": "FT",
            "index": 4,
            "value": 600
          }
        ]
      },
      "outputs": {
        "0": [
          {
            "address": "bc1q0c5aru88dtcq86ahnv09k392wnkdawkmzkxnav",
            "atomical_id": "9ba68637ba32edb6370bebceaac3df4341180cbf7bac210741b12a679692d716i0",
            "type": "FT",
            "index": 0,
            "value": 600
          },
          {
            "address": "bc1q0c5aru88dtcq86ahnv09k392wnkdawkmzkxnav",
            "atomical_id": "56a8702bab3d2405eb9a356fd0725ca112a93a8efd1ecca06c6085e7278f0341i0",
            "type": "FT",
            "index": 0,
            "value": 600
          }
        ]
      },
      "is_burned": false,
      "burned_fts": {},
      "is_cleanly_assigned": true
    }
  }
}

Merge NFTs: a10aa0f95d5ead4ad96b8060b91e5105fb5ebed89222b15ae7bca04546f606b2
It would be return like this:
{
  "success": true,
  "response": {
    "op": "transfer",
    "txid": "a10aa0f95d5ead4ad96b8060b91e5105fb5ebed89222b15ae7bca04546f606b2",
    "height": 822867,
    "tx_num": 942235266,
    "info": {},
    "transfers": {
      "inputs": {
        "0": [
          {
            "address": "bc1pnef29aqvc4tv4sxyed4ae6n7ej0f3s8arx3z337980a7yxzvf8tsd4g0fg",
            "atomical_id": "b1d0b1058b99346226b72bdae4366704ccd98b3fd3d6c023461dad3e0df88000i0",
            "type": "NFT",
            "index": 0,
            "value": 29000
          },
          {
            "address": "bc1pnef29aqvc4tv4sxyed4ae6n7ej0f3s8arx3z337980a7yxzvf8tsd4g0fg",
            "atomical_id": "b1d0cfb9c9dfdc6663589da87efe3e96458236be5521cc4bdbbefaa8384dc500i0",
            "type": "NFT",
            "index": 0,
            "value": 29000
          },
          {
            "address": "bc1pnef29aqvc4tv4sxyed4ae6n7ej0f3s8arx3z337980a7yxzvf8tsd4g0fg",
            "atomical_id": "b1d06870fd0d2801c98a49bdfd44098255fca0f3653248416df3e6eecb2e5b05i0",
            "type": "NFT",
            "index": 0,
            "value": 29000
          },
...


AmqpException when testing @RabbitListener with @RabbitHandler

Back-port issue for https://github.com/spring-projects/spring-amqp/pull/2457

Fixed via https://github.com/spring-projects/spring-amqp/commit/47b56fbcb35a1acc9bee7883e2d6aacb96fd2a48


Autotest do not stop tracking deleted files/namespaces

When deleting (or renaming) a namespace, autotest does not stop tracking the deleted file and stops running.
The error report from Midje is:
LOAD FAILURE for deletedns
Could not locate deletedns.class or deletedns.clj

I can't replicate this. Can you give me some details, perhaps using https://github.com/marick/sample-midje-project and a description of the sequence of edits/deletions needed to produce the error?

I have branched the sample project to https://github.com/dlebrero/sample-midje-project.
To reproduce checkout 6f132a3ecb092d3304905fc5d56b93568d69212d (your repo before any change), run lein midje :autotest and then checkout one step at a time.
Thanks a lot.

Sorry for the delay. I see that the sequence of steps is:

create a test file that depends on existing file.
change that existing file.
delete the new test file.

If step 2 is left out, it doesn't fail. I don't immediately see why, because Midje uses tools.namespace in a way that was... orthogonal to its original purpose. I should check if it's become more general-purpose since it was created.

I spent some time looking at the problem. The root cause is roughly this: I use clojure.tools.namespace. It's really tailored for use in the Component workflow, which is similar to - but not the same as - an autotest workflow. So I had difficulty interfacing with it. That difficulty led me to decide to ignore deleted files.
In an ideal world, part of tools.namespace would generate a model of the current filesystem. That model could be used to (periodically and efficiently) generate a new model of the new filesystem state. There would be a function that, given two models, would do reloads as required to make the runtime match (roughly) the file system. It's the "roughly" that's the problem. When files are deleted, the Component workflow wants you to take explicit action to make it disappear from the runtime. Midje is less prescriptive: it is happy to just ignore deleted files and assume their residue in the runtime is harmless. If it's not, well, then, just start autotest again.
A less opinionated library would be a really nice addition to the Clojure ecosystem. Bultitude went some distance in that direction, though it seems to be more or less about Leiningen.
In any case, I spent some time looking at the interface between Midje and tools.namespace, and I'm thinking I don't have time to fix this problem with confidence.

Thanks a lot for looking into this.
I have been playing around a bit and found that removing the deleted namespaces from the state-tracker dependencies seems to work for this particular issue.
Here is a quick and dirty patch for the midje.data.project-state ns that does the trick:
(defn prepare-for-next-scan [state-tracker]
  (let [unloaded (clojure.set/difference (set (unload-key state-tracker))
                                         (set (load-key state-tracker)))
        state-tracker (assoc state-tracker
                             time-key (latest-modification-time state-tracker)
                             unload-key []
                             load-key [])]
    (update-in state-tracker
               [:clojure.tools.namespace.track/deps :dependents]
               (fn [m]
                 (into {}
                       (map (fn [[k v]] [k (apply disj v unloaded)]) m))))))

Before spending the time to create a proper pull request, is this approach worth pursuing?

Sorry for the delay. I think that makes sense and I think it's worth giving it a try. It'll need some trial-through-use, since I'm pretty sure I didn't forget about deleted namespaces: rather, things broke when I tried to use tools.namespace for that. However, that was years ago. I don't remember the problem, and it could well have gone away on its own.
If you make a pull request, I'll use that version.


VulnerableCode returns no findings for Go packages

Describe the bug
I am scanning a project with ModGo ORT package manager.
One dependency is quic-go, release 0.40.0 , which definitely has vulnerability findings in the VulnerableCode database.
Unfortunately, no security vulnerabilites are found in the Advisor phase, using VulnerableCode.
Detailed analysis
ORT uses a "bulk search", sending a POST request to the VulnerableCode API. This request has a list of Package URLs (purls) of the dependencies like quick-go.
The purl for quick-go looks as follows:
<EMAIL_ADDRESS>So, at some places we see the "/", in other places it is percent-encoded to "%2F".
I don't want to open discussions if this is valid or not, but there is a point in saying "the / character is used to separate the parts that build up a purl, and for this reason, if a namespace or name of a dependency contain /, then they need to be percent-encoded".
When I (in code) add an additional step that replaces all occcurrences of "%2F" with "/" before I feed it into VulnerableCode, then the VulnerableCode API is happy and returns the expected vulnerability records.
Environment
ORT 34.0.0
Additional context
I will prepare a PR to deal with the issue in a pragmatic way. Stay tuned.

I don't want to open discussions if this is valid or not, but there is a point in saying "the / character is used to separate the parts that build up a purl, and for this reason, if a namespace or name of a dependency contain /, then they need to be percent-encoded".

Agreed, also regarding the topic that if VulnerableCode would be using a wrong encoding, we'd need to use a wrong encoding as well to make the lookup work.

Cross-linking the issue ticket in VulnerableCode: https://github.com/aboutcode-org/vulnerablecode/issues/1620


added debug flag

Sometimes it's nice to deploy a development server and be able to use the debugger client side, previously I set "meteorBinary": "/usr/local/bin/meteor --debug" however as of Meteor 1.2 this doesn't seem to work anymore, so I had to add this.

I'm also adding the --server option, I need this to build the app with --server set to something other than localhost, in my base I need to use SSL, so it's an --server https:// value I need to set.
It doesn't seem to work if I build it with localhost:3000


Redundant RepartitionExec in final excution plan

Describe the bug
SQL: SELECT customer.c_custkey, sum(orders.o_totalprice) as total_amount FROM customer JOIN orders ON customer.c_custkey = orders.o_custkey GROUP BY customer.c_custkey;
Generated final execution plan with datafusion v37 and default session configs:
ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount]
  AggregateExec: mode=SinglePartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
    CoalesceBatchesExec: target_batch_size=8192
      HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)], projection=[c_custkey@0, o_totalprice@2]
        CoalesceBatchesExec: target_batch_size=8192
          RepartitionExec: partitioning=Hash([c_custkey@0], 12), input_partitions=12
            RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
              ParquetExec: file_groups={3 groups: [...]}, projection=[c_custkey]
        CoalesceBatchesExec: target_batch_size=8192
          RepartitionExec: partitioning=Hash([o_custkey@0], 12), input_partitions=12
            RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
              ParquetExec: file_groups={3 groups: [...]}, projection=[o_custkey, o_totalprice]

Two RepartitionExec operators seems redundant and can be optimized into one.
To Reproduce
No response
Expected behavior
No response
Additional context
No response

can you give the plan for  explain extended for your query?
We can get the changes when going the optimizer rule

+------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| plan_type                                                  | plan
                                                                                |
+------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| initial_logical_plan                                       | Projection: customer.c_custkey, SUM(orders.o_totalprice) AS total_amount
                                                                                |
|                                                            |   Aggregate: groupBy=[[customer.c_custkey]], aggr=[[SUM(orders.o_totalprice)]]
                                                                                |
|                                                            |     Inner Join:  Filter: customer.c_custkey = orders.o_custkey
                                                                                |
|                                                            |       TableScan: customer
                                                                                |
|                                                            |       TableScan: orders
                                                                                |
| logical_plan after apply_function_rewrites                 | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after inline_table_scan                       | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after type_coercion                           | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after count_wildcard_rule                     | SAME TEXT AS ABOVE
                                                                                |
| analyzed_logical_plan                                      | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_nested_union                  | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after unwrap_cast_in_comparison               | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after replace_distinct_aggregate              | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_join                          | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after decorrelate_predicate_subquery          | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after scalar_subquery_to_join                 | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after extract_equijoin_predicate              | Projection: customer.c_custkey, SUM(orders.o_totalprice) AS total_amount
                                                                                |
|                                                            |   Aggregate: groupBy=[[customer.c_custkey]], aggr=[[SUM(orders.o_totalprice)]]
                                                                                |
|                                                            |     Inner Join: customer.c_custkey = orders.o_custkey
                                                                                |
|                                                            |       TableScan: customer
                                                                                |
|                                                            |       TableScan: orders
                                                                                |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after rewrite_disjunctive_predicate           | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_duplicated_expr               | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_filter                        | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_cross_join                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after common_sub_expression_eliminate         | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_limit                         | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after propagate_empty_relation                | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_one_union                     | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after filter_null_join_keys                   | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_outer_join                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after push_down_limit                         | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after push_down_filter                        | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after single_distinct_aggregation_to_group_by | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after unwrap_cast_in_comparison               | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after common_sub_expression_eliminate         | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after optimize_projections                    | Projection: customer.c_custkey, SUM(orders.o_totalprice) AS total_amount
                                                                                |
|                                                            |   Aggregate: groupBy=[[customer.c_custkey]], aggr=[[SUM(orders.o_totalprice)]]
                                                                                |
|                                                            |     Projection: customer.c_custkey, orders.o_totalprice
                                                                                |
|                                                            |       Inner Join: customer.c_custkey = orders.o_custkey
                                                                                |
|                                                            |         TableScan: customer projection=[c_custkey]
                                                                                |
|                                                            |         TableScan: orders projection=[o_custkey, o_totalprice]
                                                                                |
| logical_plan after eliminate_nested_union                  | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after unwrap_cast_in_comparison               | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after replace_distinct_aggregate              | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_join                          | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after decorrelate_predicate_subquery          | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after scalar_subquery_to_join                 | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after extract_equijoin_predicate              | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after rewrite_disjunctive_predicate           | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_duplicated_expr               | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_filter                        | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_cross_join                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after common_sub_expression_eliminate         | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_limit                         | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after propagate_empty_relation                | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_one_union                     | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after filter_null_join_keys                   | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after eliminate_outer_join                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after push_down_limit                         | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after push_down_filter                        | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after single_distinct_aggregation_to_group_by | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after unwrap_cast_in_comparison               | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after common_sub_expression_eliminate         | SAME TEXT AS ABOVE
                                                                                |
| logical_plan after optimize_projections                    | SAME TEXT AS ABOVE
                                                                                |
| logical_plan                                               | Projection: customer.c_custkey, SUM(orders.o_totalprice) AS total_amount
                                                                                |
|                                                            |   Aggregate: groupBy=[[customer.c_custkey]], aggr=[[SUM(orders.o_totalprice)]]
                                                                                |
|                                                            |     Projection: customer.c_custkey, orders.o_totalprice
                                                                                |
|                                                            |       Inner Join: customer.c_custkey = orders.o_custkey
                                                                                |
|                                                            |         TableScan: customer projection=[c_custkey]
                                                                                |
|                                                            |         TableScan: orders projection=[o_custkey, o_totalprice]
                                                                                |
| initial_physical_plan                                      | ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount]
                                                                                |
|                                                            |   AggregateExec: mode=FinalPartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |     AggregateExec: mode=Partial, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |       ProjectionExec: expr=[c_custkey@0 as c_custkey, o_totalprice@2 as o_totalprice]
                                                                                |
|                                                            |         HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)]
                                                                                |
|                                                            |           ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer3.parquet]]}, projection=[c_custkey]                                                                                |
|                                                            |           ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders3.parquet]]}, projection=[o_custkey, o_totalprice]                                                                                |
|                                                            |
                                                                                |
| initial_physical_plan_with_stats                           | ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount], statistics=[Rows=Inexact(150000), Bytes=Inexact(3600000), [(Col[0]:),(Col[1]:)]]
                                                                                |
|                                                            |   AggregateExec: mode=FinalPartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)], statistics=[Rows=Inexact(150000), Bytes=Absent, [(Col[0]:),(Col[1]:)]]
                                                                                |
|                                                            |     AggregateExec: mode=Partial, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)], statistics=[Rows=Inexact(150000), Bytes=Absent, [(Col[0]:),(Col[1]:)]]
                                                                                |
|                                                            |       ProjectionExec: expr=[c_custkey@0 as c_custkey, o_totalprice@2 as o_totalprice], statistics=[Rows=Inexact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(150000)) Null=Exact(0)),(Col[1]: Null=Exact(0))]]
                                                                                |
|                                                            |         HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)], statistics=[Rows=Inexact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(150000)) Null=Exact(0)),(Col[1]: Min=Exact(Int64(1)) Max=Exact(Int64(149999)) Null=Exact(0)),(Col[2]: Null=Exact(0))]]                                                                                |
|                                                            |           ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer3.parquet]]}, projection=[c_custkey], statistics=[Rows=Exact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(150000)) Null=Exact(0))]]                               |
|                                                            |           ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders3.parquet]]}, projection=[o_custkey, o_totalprice], statistics=[Rows=Exact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(149999)) Null=Exact(0)),(Col[1]: Null=Exact(0))]]     |
|                                                            |
                                                                                |
| physical_plan after OutputRequirements                     | OutputRequirementExec
                                                                                |
|                                                            |   ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount]
                                                                                |
|                                                            |     AggregateExec: mode=FinalPartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |       AggregateExec: mode=Partial, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |         ProjectionExec: expr=[c_custkey@0 as c_custkey, o_totalprice@2 as o_totalprice]
                                                                                |
|                                                            |           HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)]
                                                                                |
|                                                            |             ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer3.parquet]]}, projection=[c_custkey]                                                                                |
|                                                            |             ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders3.parquet]]}, projection=[o_custkey, o_totalprice]                                                                                |
|                                                            |
                                                                                |
| physical_plan after aggregate_statistics                   | SAME TEXT AS ABOVE
                                                                                |
| physical_plan after join_selection                         | SAME TEXT AS ABOVE
                                                                                |
| physical_plan after LimitedDistinctAggregation             | SAME TEXT AS ABOVE
                                                                                |
| physical_plan after EnforceDistribution                    | OutputRequirementExec
                                                                                |
|                                                            |   ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount]
                                                                                |
|                                                            |     AggregateExec: mode=FinalPartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |       AggregateExec: mode=Partial, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |         ProjectionExec: expr=[c_custkey@0 as c_custkey, o_totalprice@2 as o_totalprice]
                                                                                |
|                                                            |           HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)]
                                                                                |
|                                                            |             RepartitionExec: partitioning=Hash([c_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |               RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |                 ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer3.parquet]]}, projection=[c_custkey]                                                                                |
|                                                            |             RepartitionExec: partitioning=Hash([o_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |               RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |                 ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders3.parquet]]}, projection=[o_custkey, o_totalprice]                                                                                |
|                                                            |
                                                                                |
| physical_plan after CombinePartialFinalAggregate           | OutputRequirementExec
                                                                                |
|                                                            |   ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount]
                                                                                |
|                                                            |     AggregateExec: mode=SinglePartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |       ProjectionExec: expr=[c_custkey@0 as c_custkey, o_totalprice@2 as o_totalprice]
                                                                                |
|                                                            |         HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)]
                                                                                |
|                                                            |           RepartitionExec: partitioning=Hash([c_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |             RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |               ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer3.parquet]]}, projection=[c_custkey]                                                                                |
|                                                            |           RepartitionExec: partitioning=Hash([o_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |             RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |               ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders3.parquet]]}, projection=[o_custkey, o_totalprice]                                                                                |
|                                                            |
                                                                                |
| physical_plan after EnforceSorting                         | SAME TEXT AS ABOVE
                                                                                |
| physical_plan after ProjectionPushdown                     | OutputRequirementExec
                                                                                |
|                                                            |   ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount]
                                                                                |
|                                                            |     AggregateExec: mode=SinglePartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |       HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)], projection=[c_custkey@0, o_totalprice@2]
                                                                                |
|                                                            |         RepartitionExec: partitioning=Hash([c_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |           RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |             ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer3.parquet]]}, projection=[c_custkey]                                                                                |
|                                                            |         RepartitionExec: partitioning=Hash([o_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |           RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |             ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders3.parquet]]}, projection=[o_custkey, o_totalprice]                                                                                |
|                                                            |
                                                                                |
| physical_plan after coalesce_batches                       | OutputRequirementExec
                                                                                |
|                                                            |   ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount]
                                                                                |
|                                                            |     AggregateExec: mode=SinglePartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |       CoalesceBatchesExec: target_batch_size=8192
                                                                                |
|                                                            |         HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)], projection=[c_custkey@0, o_totalprice@2]
                                                                                |
|                                                            |           CoalesceBatchesExec: target_batch_size=8192
                                                                                |
|                                                            |             RepartitionExec: partitioning=Hash([c_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |               RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |                 ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer3.parquet]]}, projection=[c_custkey]                                                                                |
|                                                            |           CoalesceBatchesExec: target_batch_size=8192
                                                                                |
|                                                            |             RepartitionExec: partitioning=Hash([o_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |               RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |                 ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders3.parquet]]}, projection=[o_custkey, o_totalprice]                                                                                |
|                                                            |
                                                                                |
| physical_plan after OutputRequirements                     | ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount]
                                                                                |
|                                                            |   AggregateExec: mode=SinglePartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |     CoalesceBatchesExec: target_batch_size=8192
                                                                                |
|                                                            |       HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)], projection=[c_custkey@0, o_totalprice@2]
                                                                                |
|                                                            |         CoalesceBatchesExec: target_batch_size=8192
                                                                                |
|                                                            |           RepartitionExec: partitioning=Hash([c_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |             RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |               ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer3.parquet]]}, projection=[c_custkey]                                                                                |
|                                                            |         CoalesceBatchesExec: target_batch_size=8192
                                                                                |
|                                                            |           RepartitionExec: partitioning=Hash([o_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |             RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |               ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders3.parquet]]}, projection=[o_custkey, o_totalprice]                                                                                |
|                                                            |
                                                                                |
| physical_plan after PipelineChecker                        | SAME TEXT AS ABOVE
                                                                                |
| physical_plan after LimitAggregation                       | SAME TEXT AS ABOVE
                                                                                |
| physical_plan after ProjectionPushdown                     | SAME TEXT AS ABOVE
                                                                                |
| physical_plan                                              | ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount]
                                                                                |
|                                                            |   AggregateExec: mode=SinglePartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)]
                                                                                |
|                                                            |     CoalesceBatchesExec: target_batch_size=8192
                                                                                |
|                                                            |       HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)], projection=[c_custkey@0, o_totalprice@2]
                                                                                |
|                                                            |         CoalesceBatchesExec: target_batch_size=8192
                                                                                |
|                                                            |           RepartitionExec: partitioning=Hash([c_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |             RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |               ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer3.parquet]]}, projection=[c_custkey]                                                                                |
|                                                            |         CoalesceBatchesExec: target_batch_size=8192
                                                                                |
|                                                            |           RepartitionExec: partitioning=Hash([o_custkey@0], 12), input_partitions=12
                                                                                |
|                                                            |             RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3
                                                                                |
|                                                            |               ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders3.parquet]]}, projection=[o_custkey, o_totalprice]                                                                                |
|                                                            |
                                                                                |
| physical_plan_with_stats                                   | ProjectionExec: expr=[c_custkey@0 as c_custkey, SUM(orders.o_totalprice)@1 as total_amount], statistics=[Rows=Inexact(150000), Bytes=Inexact(3600000), [(Col[0]:),(Col[1]:)]]
                                                                                |
|                                                            |   AggregateExec: mode=SinglePartitioned, gby=[c_custkey@0 as c_custkey], aggr=[SUM(orders.o_totalprice)], statistics=[Rows=Inexact(150000), Bytes=Absent, [(Col[0]:),(Col[1]:)]]
                                                                                |
|                                                            |     CoalesceBatchesExec: target_batch_size=8192, statistics=[Rows=Inexact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(150000)) Null=Exact(0)),(Col[1]: Null=Exact(0))]]
                                                                                |
|                                                            |       HashJoinExec: mode=Partitioned, join_type=Inner, on=[(c_custkey@0, o_custkey@0)], projection=[c_custkey@0, o_totalprice@2], statistics=[Rows=Inexact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(150000)) Null=Exact(0)),(Col[1]: Null=Exact(0))]]                                                                                |
|                                                            |         CoalesceBatchesExec: target_batch_size=8192, statistics=[Rows=Exact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(150000)) Null=Exact(0))]]
                                                                                |
|                                                            |           RepartitionExec: partitioning=Hash([c_custkey@0], 12), input_partitions=12, statistics=[Rows=Exact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(150000)) Null=Exact(0))]]
                                                                                |
|                                                            |             RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3, statistics=[Rows=Exact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(150000)) Null=Exact(0))]]
                                                                                |
|                                                            |               ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/customer/customer3.parquet]]}, projection=[c_custkey], statistics=[Rows=Exact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(150000)) Null=Exact(0))]]                           |
|                                                            |         CoalesceBatchesExec: target_batch_size=8192, statistics=[Rows=Exact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(149999)) Null=Exact(0)),(Col[1]: Null=Exact(0))]]
                                                                                |
|                                                            |           RepartitionExec: partitioning=Hash([o_custkey@0], 12), input_partitions=12, statistics=[Rows=Exact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(149999)) Null=Exact(0)),(Col[1]: Null=Exact(0))]]
                                                                                |
|                                                            |             RepartitionExec: partitioning=RoundRobinBatch(12), input_partitions=3, statistics=[Rows=Exact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(149999)) Null=Exact(0)),(Col[1]: Null=Exact(0))]]
                                                                                |
|                                                            |               ParquetExec: file_groups={3 groups: [[C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders1.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders2.parquet], [C:/Users/lewis/workspace/ballista-mvp/testdata/orders/orders3.parquet]]}, projection=[o_custkey, o_totalprice], statistics=[Rows=Exact(150000), Bytes=Absent, [(Col[0]: Min=Exact(Int64(1)) Max=Exact(Int64(149999)) Null=Exact(0)),(Col[1]: Null=Exact(0))]] |
|                                                            |
                                                                                |
+------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

you can check the rule EnforceDistribution to find why the duplicate RepartitionExec added.
@lewiszlw

maybe you can check the execution config enable_round_robin_repartition for your env or the ballista default session config

enable_round_robin_repartition is default to true in Datafusion. My question is that the generated plan with default configs seems not good enough and has space to optimize.

I think the "issue" is similar to https://github.com/apache/datafusion/issues/9370

Thanks. Closing the issue as duplicated


fix: Argo workflows joins failing with wide foreach flows

Partial remedy to the issue with large foreach flows input-paths being repeated in the ARGO_TEMPLATE multiple times, exceeding the max size for it.
closes #1538

This looks good to me!

I've tested that this PR works for up to 3000-way foreach's on AWS

Can this be merged?

have to close this PR as a dead end due to the direction that Argo Workflows took with the new handling of oversized ARGO_TEMPLATE where they offload it to disk as a ConfigMap, making it not parseable in the way I had in mind in this.
This PR being only a partial fix at best lead me to a different approach, one which should be in review now and hopefully a proper solution to the issue at hand: #1704


Terminal with not launch is VS Code

Does anyone know how to fix this:
The terminal process failed to launch: Path to shell executable "/#terminal.integrated.profiles.osx#" does not exist.

Yes, you need to provide a valid path.


Is it posible to define max length and always return form control value?

Hi, me again
I noticed that the form control value is only returned when there is a valid phone number entered, is it possible to always return the input value? I tried using a valueChanged event for the control, but the returned value is always null until it's a valid one.

Also, I've found that after the entered value length is greater than 17 characters, it is no longer detected as an entered value and doesn't return the "validatePhoneNumber" control error. And if the country is changed in this state, the entered value is erased.
Video with demonstration:
https://github.com/user-attachments/assets/e8586186-e9c2-411e-b7d5-83c5a123ea74
If it could be possible to define a max param for the input, it would be great as well.
Thank you, have a good one!

Hi @mperez-TCA and thx for the coffees ;).
I've

Added the possibility to add maxLength: string | number and added 15 as his default value, as it seems to be the max world wide > available in the latest version https://github.com/rbalet/ngx-mat-input-tel/releases/tag/v18.2.0

You can add your own validators, then you'll see if you get any error directly by getting [control].value.errors. I've added you an example in the code example, here

I've seen that enablePlaceholder: boolean weren't working, so I fixed it.
I had to add some little css to make it looks cosy with two new variable, --ngxMatInputTel-selector-opacity and --ngxMatInputTel-placeholder-opacity.

I'm not sure I understand why the former maintainer didn't wanted the input to always emit the phone number. (Maybe because of poor understanding of the Validator), but I've change it

Everything & more explained in the v18.2.2


.tag vs .badge

Shouldn't the default class be .badge .badge-info for tagClass  in
https://github.com/Nodws/bootstrap4-tagsinput/blob/master/tagsinput.js#L11
given that tag is renamed in alpha6 of bootstrap? https://github.com/twbs/bootstrap/commit/d9fa3fd7971b5331b6582b46b568048458bb5544

Yes in fact I did change it but only on my project, forgot to update it here asap :P


TranslationLayer fails connection to vstest.console (portable) on M1 mac

Description
We have been using the translation layer with vstest.console from the portable package successfully for quite some time at stryker, on window, linux and mac os. Recently we have been getting reports on failure to connect to vstest.console from mac users. Specifically mac users running on M1 mac. We are not getting the reports from users on other combinations of systems.  I assume dotnet test has been tested and works on M1 mac so this leads me to believe that something in the communication between the translation layer and vstest.console might be a problem. Unfortunately none of us at stryker own an M1 mac so we are unable to troubleshoot this problem.
One other interesting thing is that even though we have logging enabled on the translation layer, no log files are generated for this failure. This is unexpected as we have seen log files generated by the translation layer before, even if connection to vstest.console failed.
Actual behavior
2022-07-27T16:35:39.4051980+03:00  [DBG] Initial build successful (61599426)
2022-07-27T16:35:39.4379660+03:00  [DBG] VsTest zip was copied to: "/var/folders/0d/kw0r8pcx1rn06j4d2g_bmjj00000gn/T/o2gew0gf.rrm/.vstest/vstest.zip" (8e340ff1)
2022-07-27T16:35:39.5826230+03:00  [DBG] VsTest zip was unzipped to: "/var/folders/0d/kw0r8pcx1rn06j4d2g_bmjj00000gn/T/o2gew0gf.rrm/.vstest" (679800d3)
2022-07-27T16:35:39.5865320+03:00  [DBG] Using vstest from deployed vstest package (6132c740)
2022-07-27T16:35:39.5877890+03:00  [DBG] Using vstest.console: "OSX" for OS "/var/folders/0d/kw0r8pcx1rn06j4d2g_bmjj00000gn/T/o2gew0gf.rrm/.vstest/tools/netcoreapp2.1/vstest.console.dll" (38dfd549)
2022-07-27T16:35:39.6004950+03:00  [INF] Time Elapsed 00:00:03.4676349 (f4427d77)

Unhandled exception.

Stryker failed to connect to vstest.console

Diagnostic logs

Please share test platform diagnostics logs. Instructions to collect logs are here.
The logs may contain test assembly paths, kindly review and mask those before sharing.
No log files were generated even though logging is enabled: https://github.com/stryker-mutator/stryker-net/issues/2117
Confirmed on my own system that logs are generated, user system does not generate logs with the same logging settings.

Environment

Please share additional details about the test environment.
Operating system, Build version of vstest.console

OS: [MacOS 12.4 (21F79] Macbook M1
Framework Version [.NET 6]

<PackageReference Include="Microsoft.TestPlatform" Version="17.2.0" />
<PackageReference Include="Microsoft.TestPlatform.ObjectModel" Version="17.2.0" />
<PackageReference Include="Microsoft.TestPlatform.Portable" Version="17.2.0" />
<PackageReference Include="Microsoft.TestPlatform.TranslationLayer" Version="17.2.0"

Note, I see that we are swallowing the exception coming from the translation layer so I will be changing that and releasing a new version so we at least have that information available.

@rouke-broersma I see that the linked issue was closed as not reproducible. Are you still experiencing the issue?

@Evangelink Hi, thank you for replying! The original issue creator has not replied to our requests for more information and we finally found someone with an M1 Mac willing to test. They had no issues. As far as I'm concerned the issue can be closed.

@evangelink we have a new report of the same issue, again on m1 mac. The additional logging does not expose any more information: https://github.com/stryker-mutator/stryker-net/issues/2117

@Evangelink if I can provide any additional data in some way pls let me know.

Seems like this was fixed by updated to 17.5


edit User option

edit user design and funcionality

search by club house
fetch user by specific club house
upload current user data
abillty to change user data
abillty to remove user data

done all function.
need only to work on abillty to change user data


Feature/issue 63 make messages only compare equal to messages

Ready for review.

Looks good, go for it.

Thanks Simon, good catch. Happy for this to land, it's mostly historical cruft so thanks for cleaning up.


Updated version of grunt-sass from 0.14 to 0.16

Fixing Assertion failed: (val->IsString()) error which was a bug in sass compiler in 0.14 version.

Thanks for the PR :+1:
I'm hesitant to update to the latest grunt-sass due to the broken sourcemaps (https://github.com/sindresorhus/grunt-sass/issues/166). The good news here though is that node-sass 2.0 is in beta and once it is released, grunt-sass will be updated, and then I will update Yeogurt.
For now, is it is up to the author to update this dependency after generating a project.
Feel free to keep this PR open if you would like to handle updating grunt-sass once the next release comes out.
Cheers!


Refetch queries

Queries sometimes need to be refetched, possibly with new arguments

Currently have a use case where I need to manipulate filters on the page and re-run a query with the filters adjusted (from query variables). Is this the use case you are referring to here?

Yep! that's exactly right. Atm, your best bet is to embed as much as you can in the URL filters so you can use page transitions to cause a new query to be fired.
If you feel up for adding this, I don't think many changes are needed. Here is where the return value from query is defined. I'm pretty sure all it would take would be adding the function to this object that fires the query (using fetchQuery from the exported runtime) and passes the result to the same writeData function in that object to update the cache values and subscriptions for the query.

I started working on this here.
I have some issues with the houdini build:cmd:main command sed -i '#!/usr/bin/env node' build/cmd.js, sed: undefined label. Im on Mac and it seems like mac needs another required argument on sed -i https://mpdaugherty.wordpress.com/2010/05/27/difference-with-sed-in-place-editing-on-mac-os-x-vs-linux/
Otherwise its working pretty well, can u look at this @AlecAivazis and tell me what, or if im missing something in my implementation.

One thing that came to my mind is: Should we return the result of the fetch {data, error} or just void?

Feel free to remove that whole sed command from package.json - its not necessary and is left overs from the kit effort that I have been meaning to remove

One thing that came to my mind is: Should we return the result of the fetch {data, error} or just void?

I think returning the data object might make sense. In cases where you just want differentiate from the new data, I think it makes sense to capture the return value (i.e., data tables where you show X records per page). Of course, this should still update the cache.

I wonder if differentiating new and old data is better done in a reactive statement so that we don't have to complicate houdini's api 🤔

That could work. I guess my thought was getting the incremental difference, not storing the previous state before the query.
For example, returning the 25 new records to render the next page without having to calculate the diff of the old and new state. It could still be done with a reactive statement though, so I'm definitely okay with keeping the API slimmer.

Any docs for this yet?


Library keys changing after new IDE

@tanaikech sensei, I think some of the libraries keys have changed because of GAS new IDE (e.g.:  Moment.js key was MHMchiX6c1bwSqGM1PZiW_PxhMjh3Sh48, but now is 15hgNOjKHUG4UtyZl9clqBbl23sDvWMS8pfDJOyIapZk5RBqwL3i-rlCo).
Do you know if there is an easy way to automatically update the database with the new keys?

Thank you for your comment. In this library, the data is retrieved from 2 database. One is from my database. Another is from Andrew Roberts's database The libraries in your comment are from Andrew Roberts's database. So in this case, it is required to modify it. About this, how about reporting it to Andrew Roberts?

Thanks! 🙇🏻♂
I'll report it to him too.


Remove Component validation in html! to allow for generic components

Because this validation check tries to impl Component for the component
type, generic components could not have been used.
With this change, it is possible to write a component like this:
impl<C> Component for TreeView<C>
    where C: Component,
{
    type Message = Msg;
    type Properties = TreeData<<C as Component>::Properties>;
    ...
    fn view(&self) -> Html {
        if self.props.expanded {
            html! {
                <div>{
                    for self.props.children.iter().cloned()
                            .map(|child| html! {
                                <TreeView<C>
                                    element={child.element}
                                    children={child.children}
                                    expanded={child.expanded}
                                />
                            })
                }</div>
            }
        } else {
            html!{}
        }
    }
    ...
}

See more details in this issue: #1064

Take a look at the tests that we run in CI.. The macro test is going to fail because the compiler error message will be different

Oops, macro tests were not running. Could you please rebase off last master and fix the tests?

Guide: https://github.com/yewstack/yew/blob/master/CONTRIBUTING.md#macro-tests

Guide: https://github.com/yewstack/yew/blob/master/CONTRIBUTING.md#macro-tests

There is a broken link in the guide for the stderr file.
Because I had some problems, I checked out master at 393eb8 and when I run
TRYBUILD=overwrite cargo test --test macro_test

I get
error: no test target named `macro_test`

Running the tests with
./ci/run_tests.sh

yields
...
error: test failed, to rerun pass '--lib'

Caused by:
  could not execute process `wasm-bindgen-test-runner /home/linusb/git/yew/target/wasm32-unknown-unknown/debug/deps/yew-88efceb071029c6b.wasm` (never executed)

Not sure where this is coming from. Do you have any problems running the tests on the current master?

@mankinskin you'll have to run that command from ./crates/macro

Yes indeed, it might be confusing at first, but at least it contains the helpful error at the end :) But it would still be interesting to know how to get the trait bounds of a generic type argument from a proc macro ..
But well, thank you for helping me contribute to this awesome project!

but at least it contains the helpful error at the end :)

Haha yes very true!

But it would still be interesting to know how to get the trait bounds of a generic type argument from a proc macro ..

Yeah, I think it's possible. We can inspect and validate the generics from the component type if present. Just don't have time to do so now :)

🎉 released in v0.14.3


Stripe Icon

Describe the requested icon
We integrate with Stripe and have a section for users to configure their stripe settings etc.
Screenshots
We were using MaterialDesignIcons.com, here's our settings screen before I started switching the icons over to Phosphor:

And here it is with Phosphor:

Dashboard looks great :) I think we can accommodate a Stripe logo.

stripe-logo  added in v1.3.1!


Create Periodic backups of sprig data

Create a periodic backup of sprig data from firebase

GCloud now creates backups of the Sprig firestore database every week on Tuesday at 7pm UTC with a 4 weeks retention time.


feat: Enable Prism for copy code button

Description
Fixes: #70

@thrau @whummer please take a look.

Unfortunately the prism syntax highlighting is not compatible with our command shortcode (i.e. it breaks when you activate prism). This shortcode makes sure that you can easily copy our commands in the docs (where is prevents the selection of the $  prefix).
You can verify that by starting the hugo page (hugo serve) and then trying to select or copy commands (for example the pip install command here).
I'm afraid that you will need to (heavily?) adjust the shortcode before you can enable the prism syntax highlighting.


Jose

First draft of my Use-Case.

on the diagram, Burglurize should be Burglarize

also put in how root access and ssh is disabled at the beginning to help prevent it that may be helpful
also a keyring will help protect the password to the Tesla API because it will not be in plain text like it would be in the config.yaml

Also may want to talk about a man in the middle attack where the attacker tries to sniff the traffic from HA to the API

also put in how root access and ssh is disabled at the beginning to help prevent it that may be helpful
also a keyring will help protect the password to the Tesla API because it will not be in plain text like it would be in the config.yaml

Good point, I read about this but the documentation did not specify this was by default. I had edited the use-case to account for this. For this situation Bob disables this feature for convenience.

Changes look good, approving to push to master.


Improve legacy build parsing of image ID

Apologies for not realising this was a better way to do it from the start... It turns out the original method doesn't work with podman, which gives slightly different output when not using --quiet.

Sadly here, if an issue occurs, we will loose some debugging information in the exception as the quiet flag is always used.

Good point that this is a concern, however in the case the build errors the relevant output will go to stderr and will still be included in the exception. Examples below.
Docker output:
root@ubuntu:~/rebuild# docker build . -q > /dev/null
Sending build context to Docker daemon  2.048kB
Step 1/5 : FROM ubuntu AS stage1
 ---> 7c73d141098a
Step 2/5 : RUN echo foo > /foo
 ---> Using cache
 ---> 9c15ea17132c
Step 3/5 : FROM stage1 AS stage2
 ---> 9c15ea17132c
Step 4/5 : RUN echo bar > /bar
 ---> Using cache
 ---> e8adacd0486f
Step 5/5 : COPY baz /
COPY failed: file not found in build context or excluded by .dockerignore: stat baz: file does not exist

Podman output:
root@ubuntu:~/rebuild# podman build . -q
Error: error building at STEP "COPY baz /": checking on sources under "/root/rebuild": copier: stat: "/baz": no such file or directory

So I think still this change is 'correct', i.e. more robust without sacrificing debuggability.

It's all good for docker then if they still print everything in case of errors. For podman, won't that be annoying to not have the full output?
On a completely independent note I also wonder if podman will one day use buildkit, which would simplify the interfacing we're doing now.

It's all good for docker then if they still print everything in case of errors. For podman, won't that be annoying to not have the full output?

That podman error seems ok to me.

On a completely independent note I also wonder if podman will one day use buildkit, which would simplify the interfacing we're doing now.

I'm not sure, podman uses buildah, which I guess is completely separate?

Seems ok to me then. We can always talk about it again if someone is complaining about the podman output. Changing this does not necessarily means breaking the api so we'll have flexibility.
I won't make a new release right away, you can always use the fix by pip installing this package from github :)

I won't make a new release right away, you can always use the fix by pip installing this package from github :)

Yeah, I've been doing this for testing. No immediate release is not a problem since I was just experimenting with Podman at this point, but I'm reluctant to pin to github in my requirements.txt, so in some cases a release is very much appreciated (hence my asking before).


#118: Add missing 'dot' format in usage text

Closes #118

Codecov Report

Merging #119 (e394831) into main (5c26510) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #119   +/-   ##
=======================================
  Coverage   86.24%   86.24%
=======================================
  Files          14       14
  Lines         407      407
=======================================
  Hits          351      351
  Misses         40       40
  Partials       16       16

Impacted Files
Coverage Δ

cmd/root.go
90.00% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5c26510...e394831. Read the comment docs.