tauri-cli fails to build and install from crates.io using cargo install

Describe the bug
The version of tauri-cli currently packaged on crates.io (https://crates.io/crates/tauri-cli, version 1.0.0-beta.7) fails to build and install using cargo. Command and truncated error output:
$ cargo install tauri-cli --version 1.0.0-beta.7

[... many dependency packages skipped ...]

   Compiling tauri-cli v1.0.0-beta.7
   Compiling tauri-bundler v1.0.0-beta.4
error[E0432]: unresolved import `clap::crate_version`
 --> /home/bnewbold/.cargo/registry/src/github.com-1ecc6299db9ec823/tauri-cli-1.0.0-beta.7/src/main.rs:6:12
  |
6 | use clap::{crate_version, load_yaml, App, AppSettings, ArgMatches};
  |            ^^^^^^^^^^^^^ no `crate_version` in the root

error: cannot determine resolution for the macro `crate_version`
   --> /home/bnewbold/.cargo/registry/src/github.com-1ecc6299db9ec823/tauri-cli-1.0.0-beta.7/src/main.rs:265:14
    |
265 |     .version(crate_version!())
    |              ^^^^^^^^^^^^^
    |
    = note: import resolution is stuck, try simplifying macro imports

error[E0308]: mismatched types
   --> /home/bnewbold/.cargo/registry/src/github.com-1ecc6299db9ec823/tauri-cli-1.0.0-beta.7/src/main.rs:264:23
    |
264 |   let app = App::from(yaml)
    |                       ^^^^ expected struct `App`, found `&yaml_rust::yaml::Yaml`

Some errors have detailed explanations: E0308, E0432.
For more information about an error, try `rustc --explain E0308`.
error: failed to compile `tauri-cli v1.0.0-beta.7`, intermediate artifacts can be found at `/tmp/cargo-installihgagI`

Caused by:
  could not compile `tauri-cli` due to 3 previous errors

Checking out this repo and running cargo build in the subdirectory tooling/cli.rs/ works, so I suspect that the version in crates.io is just out of date. I would speculate that at some point the Rust dependencies were not locked or specified tightly enough.
To Reproduce

Install current Rust toolchain, eg using rustup
Run the above install command

Expected behavior
Rust package compiles and is installed for current user, and cargo tauri command works.
Platform and Versions (required):
After building the rust CLI from a git checkout (d56a7fc7f7d0575061da9ecd70ba23a5ee0bf8e2), running ./target/debug/cargo-tauri info gives:
Operating System - Debian, version 10 X64
WARNING: no lock files found, defaulting to npm

Node.js environment
  Node.js - 17.2.0
  @tauri-apps/cli - 1.0.0-beta.10
  @tauri-apps/api - Not installed

Global packages
  npm - 8.1.4
  pnpm - Not installed
  yarn - 1.12.3

Rust environment
  rustc - 1.57.0
  cargo - 1.57.0

Rust environment
  rustup - 1.24.3
  rustc - 1.57.0
  cargo - 1.57.0
  toolchain - stable-x86_64-unknown-linux-gnu (d

App directory structure
/webview-src
/.changes
/examples
/.github
/webview-dist
/src

App
  tauri.rs - no manifest (no lockfile)
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws:
  distDir - ../public
  devPath - http://localhost:5000/
  bundler - Rollup

Additional context
I searched for open issues here and in discussions before opening this bug. I encountered this following the "Getting Started" guide on https://tauri.studio. The exact command recommended there is:
cargo install tauri-cli --version ^1.0.0-beta

I narrowed to the exact version to confirm the problem existed with the latest published version.
By the way, thank you for developing/maintaining Tauri! The small install sizes are really impressive, and it is pretty cool that it targets Linux (both .deb and Appimage) out of the box.

duplicate of #3050.
You can install from git for now: cargo install tauri-cli --git https://github.com/tauri-apps/tauri

Ah, thanks, and thanks for the quick reply!
I think I didn't see because I didn't search closed issues.


General Clean-ups of Documentation and Public API ahead of first release

One thing I'd advocate for (maybe prior to publishing on crates.io) is to recreate the ROS tutorial in a mdbook and then host it with Jekyll from a GitHub repo. This will make it easier to show how to get started.

One thing I'd advocate for (maybe prior to publishing on crates.io) is to recreate the ROS tutorial in a mdbook and then host it with Jekyll from a GitHub repo. This will make it easier to show how to get started.

Filed https://github.com/Carter12s/roslibrust/issues/22


Add IndexedDB database backend, routing, search, sharing sidebar

Fixes #72
Fixes #42
Fixes #34
Fixes #13
Apologies for doing this as such a big PR, but this essentially changes the underpinnings of the whole app, which affected everything.  I'll try to discuss and demo everything, and you can ask questions on whatever isn't clear.
Database
I'm using Dexie, which is built on top of IndexedDB, and provides some nice reactivity for queries.  Dexie allows for import/export using a JSON format, which I've included via an Export button in the User Settings dialog.  This will let us move to another backend later if we decide to innovate on that part of things.  However, I don't think we're going to improve on what Dexie offers.
The database is split into two tables:

chats - this is a ChatCraftChat object, but the messages are only stored as ids vs. full messages
messages - this is a ChatCraftMessage object, but we also include the chatid of the chat which owns it.

I've split the messages out of the chats so that search is easier to do (i.e., I only do search on message contents).
Both chats and messages have an autogenerated nanoid id.  This is used in various ways, including routing.
Routing
We used to only have a single route, /.  Now we have the following routes (defined in src/router.ts):

/ the default entry point, redirects to /new and creates a new chat by default
/new creates a new chat and redirects to it
/c/:chatId loads a chat by id from the database and displays it
/c/:chatId/fork/:messageId? forks the chat at chatId (i.e., creates a new chat with same messages).  If a messageId is present, forks from that message vs. all messages (e.g., fork half-way through a chat)
/c/:user/:chatId loads a shared chat over the network
/s?q=... searches across all messages for ... and shows results

UI
The UI has been updated.  Here's what a chat looks like:

I can also open the sidebar to show my shared chats (I don't have any at the moment, and need to land this on prod to fully test that bit):

Notice the URL: http://localhost:5173/c/cOwwpnz-l-3TaTcoMxFDB. This shows that I'm in the chat with id=Owwpnz-l-3TaTcoMxFDB. If you open that same URL in another tab, the messages will be synced (i.e., they display the same live data).
Notice too that messages now have a date/time link.  The message in this view has the URL: http://localhost:5173/c/cOwwpnz-l-3TaTcoMxFDB#abUKHyapxo576etk4pSsn, which is chat id=cOwwpnz-l-3TaTcoMxFDB and messageId=abUKHyapxo576etk4pSsn. This #messageId hash lets me deep-link into a conversatation
As a chat grows, each message gets its own unique link, which I can open in a new tab, bookmark, etc:

At the bottom of the form, there are two links:

New - starts a new blank chat.
Fork - starts a new chat using this chat as the starting point

Both can be right-clicked to open in a new tab/window.
I can also Fork from a message in the middle of a chat using the menu:

Search
In the Header there is now a Search form.  I can type some text and press Enter or click the Search button:

Searches look for your input text anywhere in the message text, across all messages in your history.  They are returned in reverse chronological order.
You can open the chat to which the message belongs by clicking on the Date/Time link.  Or you can fork a new chat from that message using the menu.
Breaking Changes and Bugs

This will lose the user's current chat in localStorage.  However, after the first load, the db will be stable.  Users can also request that the database be persisted (not deleted by browser without permission) in settings:

The token counting is not connected to the new backend yet.  We can fix as part of #61.  We also need to remove src/hooks/use-messages.ts

App.tsx has been renamed to Chat.tsx, and there is some code duplication between Chat.tsx and Search.tsx that we could clean up with React Router child routes and <Outlet />s.  It wasn't enough to worry about in this change.

I need to track a setting in storage for whether or not the sidebar is default open/closed, but didn't bother yet.

There's a slight difference between the types for what's in the database (src/lib/db.ts) and the ChatCraftMessage and ChatCraftChat classes.  I think I've dealt with all of it, but we could probably add some more helper methods to convert between types.  For now, this is working.

Current shared chats are going to break, since the URL structure is different.  I think we should just empty the bucket, but if something there is important, we can manually fix.

Other Changes

I moved the main UI over to use CSS Grid instead of all Flexbox, and it's working a lot better.

I've introduced a readonly mode to the Chat so that we can show a chat you don't own/have in the db (e.g., load a share).

I had to change a bunch of props to deal with passing both messageId and chatId

I've made the "enter your api key" instructions less of a deal-breaker.  Right now you can't get passed them if you want to read.  Now you can.

I added a simple summarization algorithm for the default summary we use when not invoking OpenAI to generate.  The only time we need this is for sharing.  See src/lib/summarize.ts.  There's probably something smarter we can do without needing an AI/model, but this works for now, and users can click Generate to have OpenAI write one instead.

This is really good.
Thoughts:

I would prefer to have 'new'/'fork' chat open a new window now by default. This helps reinforce the idea that old chats don't go away
When you click new, it's not clear that chat history is retained...I would display an indicator saying "131323 saved chats" next to search box
Not clear what share urls look like now.

Issues:

Our message asking for key also shows the helpful assistant message above it
search should be case-insensitive by default


[vcpkg] find_package treats OPTIONAL_COMPONENTS as obligatory

Describe the bug
I have a following declaration in my CMakeLists.txt:
find_package(Qt5 5.6 REQUIRED
  COMPONENTS Core DBus Widgets Svg Xml Test PrintSupport
  OPTIONAL_COMPONENTS Sql Concurrent QuickWidgets)

Despite the fact that some components are designated as optional with OPTIONAL_COMPONENTS, vcpkg ignores that switch and fails:
CMake Error at /Volumes/External/Sourcecode/vcpkg/scripts/buildsystems/vcpkg.cmake:555 (_find_package):
  Could not find a package configuration file provided by "Qt5QuickWidgets"
  with any of the following names:

    Qt5QuickWidgetsConfig.cmake
    qt5quickwidgets-config.cmake

  Add the installation prefix of "Qt5QuickWidgets" to CMAKE_PREFIX_PATH or
  set "Qt5QuickWidgets_DIR" to a directory containing one of the above files.
  If "Qt5QuickWidgets" provides a separate development package or SDK, be
  sure it has been installed.
Call Stack (most recent call first):
  cmake-build-debugfull-vcpkg/vcpkg_installed/x64-osx/share/cmake/Qt5/Qt5Config.cmake:28 (find_package)
  /Volumes/External/Sourcecode/vcpkg/scripts/buildsystems/vcpkg.cmake:555 (_find_package)
  CMakeLists.txt:91 (find_package)

Only after removing the QuickWidgets from OPTIONAL_COMPONENTS altogether it continues with installation.
Environment

OS: macOS

Expected behavior
OPTIONAL_COMPONENTS should be exactly that – optional.

cc @Neumann-A

vcpkg ignores that switch and fails:

let me correct this: I did not make any changes to the XXXXConfig.cmake of Qt - which I am aware of - which would change the upstream behavior regarding those keywords. As such this is not a vcpkg issue but an upstream Qt issue. Looking at the Qt5BasicConfig.cmake.in there is no handling for <PackageName>_FIND_REQUIRED_<c> so it is highly likely that it is simply not support by the current upstream Qt configs.
From what I see in the configs you could try to use two calls instead:
find_package(Qt5 5.6 REQUIRED COMPONENTS Core DBus Widgets Svg Xml Test PrintSupport)
find_package(Qt5 5.6 COMPONENTS Sql Concurrent QuickWidgets)

let me correct this: I did not make any changes to the XXXXConfig.cmake of Qt - which I am aware of - which would change the upstream behavior regarding those keywords. As such this is not a vcpkg issue but an upstream Qt issue. Looking at the Qt5BasicConfig.cmake.in there is no handling for <PackageName>_FIND_REQUIRED_<c> so it is highly likely that it is simply not support by the current upstream Qt configs.

I suppose that in this case the cmake-packages manpage is quite misleading: even if it does make a point that the "Handling of COMPONENTS and OPTIONAL_COMPONENTS is defined by the package", the examples it uses that it is supported by the Qt itself :
Both types of packages also support specifying components of a package, either after the REQUIRED keyword:

find_package(Qt5 5.1.0 CONFIG REQUIRED Widgets Xml Sql)
or as a separate COMPONENTS list:

find_package(Qt5 5.1.0 COMPONENTS Widgets Xml Sql)
or as a separate OPTIONAL_COMPONENTS list:

find_package(Qt5 5.1.0 COMPONENTS Widgets
                       OPTIONAL_COMPONENTS Xml Sql
)
Handling of COMPONENTS and OPTIONAL_COMPONENTS is defined by the package.

From what I see in the configs you could try to use two calls instead:
find_package(Qt5 5.6 REQUIRED COMPONENTS Core DBus Widgets Svg Xml Test PrintSupport)
find_package(Qt5 5.6 COMPONENTS Sql Concurrent QuickWidgets)

This does work indeed.


Update approvers.go

Handling usernames with whitespace issue = https://github.com/trstringer/manual-approval/issues/43

Thank you for your contribution!!


Enhance js-sdk-contrib to support web components

We need to support the creation of web-components. This involves:

adding nx templates for such components
adding associated documentation
one example already exists: https://github.com/open-feature/js-sdk-contrib/issues/250

This is done


--debug flag to k3s command overridden by server subcommand

Version (k3OS / kernel)
k3os version v0.10.0
5.0.0-43-generic #47~18.04.1 SMP Wed Apr 1 16:27:01 UTC 2020
Architecture
x86_64
Describe the bug
I have the same error as #454 and thought I should add debugging and reinstall my cluster from scratch. However, when I add the --debug option to the k3s command in my config.yaml-file, it appears that the argument server is added when it's not the first argument which causes the k3s command to fail. I.e., instead the command /sbin/k3s --debug server .... it changes into /sbin/k3s server --debug server ... which throws an error since the --debug flag is unknown to the server subcommand.
To Reproduce
config.yaml containing:
k3os:
  k3s_args:
    - "--debug"
    - server
    - "--cluster-init"

Expected behavior
That the k3s start command is:
/sbin/k3s --debug server --cluster-init
and thus succeeds.
Actual behavior
That the k3s start command is:
/sbin/k3s server --debug server --cluster-init
which fails.

@neerdoc a k3os.environment entry ought to do the trick, e.g.:

I tried that now, although it turned out it should be (no hyphen):
k3os:
  environment:
    K3S_DEBUG: true

It certainly prints out a lot more information in the k3s-service.log, but it does not look like it is the same debug messages as if I supply the --debug flag directly on the command line.


feat: badges with category and badge_type fields

Summary of Changes

Extend badge data model in the backend
Provide ingestion API for the updated badge model

Tests
Added tests for BadgeAPI, TableBadgeAPI, and DashboardBadgeAPI
Modified tests for Table and Dashboard
Documentation
What documentation did you add or modify and why? Add any relevant links then remove this line
CheckList
Make sure you have checked all steps below to ensure a timely review.

[ ] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[ ] PR includes a summary of changes.
[ ] PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does

[ ] PR passes make test

Do we want to set up a way to enforce a specific name, category, badge type combination when allowing someone to add a badge? Or do we want to allow badges based on only whitelisted badge names as we do right now? @feng-tao @ttannis @dikshathakur3119 @Golodhros

Do we want to set up a way to enforce a specific name, category, badge type combination when allowing someone to add a badge? Or do we want to allow badges based on only whitelisted badge names as we do right now? @feng-tao @ttannis @dikshathakur3119 @Golodhros

Added configuration to address this and it can be overwritten by a custom configuration.

Codecov Report

Merging #176 into master will decrease coverage by 1.51%.
The diff coverage is 71.07%.

@@            Coverage Diff             @@
##           master     #176      +/-   ##
==========================================
- Coverage   74.10%   72.59%   -1.52%
==========================================
  Files          25       30       +5
  Lines        1255     1536     +281
  Branches      136      171      +35
==========================================
+ Hits          930     1115     +185
- Misses        297      380      +83
- Partials       28       41      +13

Impacted Files
Coverage Δ

metadata_service/api/user.py
100.00% <ø> (ø)

metadata_service/proxy/gremlin_proxy.py
45.78% <50.00%> (+0.32%)
:arrow_up:

metadata_service/proxy/neo4j_proxy.py
71.53% <50.98%> (-3.47%)
:arrow_down:

metadata_service/api/badge.py
59.25% <59.25%> (ø)

metadata_service/proxy/base_proxy.py
67.08% <66.66%> (-0.06%)
:arrow_down:

metadata_service/proxy/atlas_proxy.py
80.89% <74.54%> (-3.41%)
:arrow_down:

metadata_service/__init__.py
76.47% <100.00%> (ø)

metadata_service/api/dashboard.py
82.60% <100.00%> (+9.27%)
:arrow_up:

metadata_service/api/table.py
100.00% <100.00%> (ø)

metadata_service/api/tag.py
92.59% <100.00%> (-0.27%)
:arrow_down:

... and 8 more

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 a680282...baacca8. Read the comment docs.

@allisonsuarez feel free to ping again once the pr is up to date for final review.

@allisonsuarez feel free to ping again once the pr is up to date for final review.

having some issues when testing locally, I will after those are resolved

@feng-tao


[bug]: installing with bun causes issue where "INTERNAL_DO_NOT_USE__fatalClientError" is not an import from uploadthing/client

Provide environment information
System:
    OS: Linux 6.5 Pop!_OS 22.04 LTS
    CPU: (12) x64 AMD Ryzen 5 5600G with Radeon Graphics
    Memory: 4.06 GB / 14.98 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 18.18.2 - ~/.nvm/versions/node/v18.18.2/bin/node
    npm: 9.8.1 - ~/.nvm/versions/node/v18.18.2/bin/npm
    bun: 1.0.11 - ~/.bun/bin/bun
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 119.0.6045.123
  npmPackages:
    @uploadthing/react: latest => 6.0.0
    typescript: ^5.1.6 => 5.2.2
    uploadthing: latest => 6.0.1

Describe the bug
updated the uploadthing package from 5.7.4 to 6.0.0 using bun. Doing so resulted in the error mentioned in the title.
Afterwards, clearing node_modules and bun.lockb and installing with npm resolved this issue
Link to reproduction
https://docs.uploadthing.com/getting-started/appdir
To reproduce
Upgrade to the latest version of uploadthing using bun
Additional information
No response
👨👧👦 Contributing

[ ] 🙋♂ Yes, I'd be down to file a PR fixing this bug!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

is this a bug in bun? it feels like it might be

Got this error after updating from v6.4.1 to v6.5.2 (all with npm). Fixed by deleting node_modules and package-lock.json.

Unable to repro this on latest version. Judging from @sgalanb's comment, it seems like this was likely an issue with cached dependencies.
Closing for now, feel free to reopen if you encounter this issue again, and have repro steps to share.


Fixed sonar cloud smell

FRONTEND PULL REQUEST
Related Issue

Resolves #5594

Changes Proposed
Modify regex to use the characters directly.
Testing
Verify that the sign up flow validates the zipcode.
Verify the add facility flow validates the CLIA.

Currently waiting for an environment to deploy the code

I have deployed in dev5 and is working as expected. Please feel free to test and review :D.


Uncaught TypeError: Cannot read property 'is' of null

Uncaught TypeError: Cannot read property 'is' of null
Atom Version: 0.156.0
System: linux 3.14.26-1-lts
Thrown From: tree-view-open-files package, v0.1.9
Steps To Reproduce

open an atom project with the tree view hidden
press `ctrl+' on linux to open the tree view

btw: pressing ctrl+0 opens the tree view w/o error and after that ctr+\ works as well
Stack Trace
At /home/despairblue/.atom/packages/tree-view-open-files/lib/tree-view-open-files.coffee:17

TypeError: Cannot read property 'is' of null
  at atom-workspace.<anonymous> (/home/despairblue/.atom/packages/tree-view-open-files/lib/tree-view-open-files.coffee:17:25)
  at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/usr/share/atom/resources/app/src/command-registry.js:243:29)
  at /usr/share/atom/resources/app/src/command-registry.js:3:61
  at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/usr/share/atom/resources/app/node_modules/atom-keymap/lib/keymap-manager.js:549:16)
  at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/usr/share/atom/resources/app/node_modules/atom-keymap/lib/keymap-manager.js:391:22)
  at HTMLDocument.module.exports.WindowEventHandler.onKeydown (/usr/share/atom/resources/app/src/window-event-handler.js:167:20)

/cc @atom/core

@Try this, fixed for atom 1.18.0 https://github.com/sergiu-gordienco/tree-view-open-files
on atom is tree-view-open-files-updated
apm install tree-view-open-files-updated
https://atom.io/packages/tree-view-open-files-updated


Consistency with last build's description and badge

Hello,
With the latest released version of the build monitor plugin, when a new build starts, the bottom left of the job's visual updates to the latest build name and the previous build's description is also cleared as the new build starts.  However, the previous build's groovy badge will still remain, which seems a little misleading to me, as everything else on the visual is changed with the new build in progress, except the badge.  Can the badge also be removed when a new build starts?
Thanks!

Hey @johnbieren and thanks for reporting this. That's a good point; I'll look into this when I have a moment and am also happy to accept pull requests solving this problem.

As long as we have color of previous build still showing on progress (red if previous build has failed), we need to see badges from previous build because usually badges show us reason of previous build failure.
Also cleaning of badges can be done as first step of build which is mush easier than copying all of badges from previous build now.


chore(master): release 0.12.0

:robot: I have created a release beep boop
0.12.0 (2024-05-03)
Features

updating from newer svd2rust (#81) (dc69366)
updating from newer svd2rust (#83) (3e32ed8)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/xmc-rs/xmc4400/releases/tag/v0.12.0 :sunflower:


switch to a more declarative config for bundle_conda

Description

Type of change

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

References

https://github.com/napari/napari/issues/4395
https://github.com/napari/napari/issues/1001#issuecomment-1090348981

How has this been tested?

[x] conda bundle CI passes

Final checklist:

[X] My PR is the minimum possible work for the desired functionality
[X] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If I included new strings, I have used trans. to make them localizable.
For more information see our translations guide.

@goanpeca - this is ready for a first look! the main changes are in setup.cfg, the rest is to accommodate the implications of having the specs out of conda-native metadata files :D

@jaimergp could you write a bit more about all the work here? Some notes:

I don't love the "$channels" and "$dependencies" in the workflow — seems opaque, I don't know where they come from?
For me, the whole point of using setup.cfg is to avoid duplicating the dependency declarations. If we are going to have a whole new section with the same dependencies (in addition to others), then why not just have a meta.yaml?

@jni

$channels and $dependencies come from here, two lines above. That shell script takes the data from setup.cfg (notice how we pass the "key" of the section as an argument). Why shell? Because we need this data to set up the Python environment, so we don't have it around yet.

I don't like it either because it's almost redundant, but it's not :/ Packages are mostly the same, but some have subtly different names, and we also need to deal with conda-specifics like variant selectors and so on. It also uses a slightly different syntax. Most version operators are the same, but some of the ones used in PyPI are not available in conda (like =~).

We "have" a meta.yaml in the conda-forge feedstock already, which we are cloning in the CI, and then patching programmatically through bundle_conda.py --patch-recipe (new addition in this PR) to override what we have in the stable release with the latest needs of our development version. Before this we were blindly taking the latest release as source of truth, potentially producing bad nightlies. The problem here is that our conda-forge releases come after the PyPI releases and the constructor installers.

I still need to update the docs to reflect our final workflow, but I am asking for this kind of feedback first to ensure we all like it.

We "have" a meta.yaml in the conda-forge feedstock already, which we are cloning in the CI, and then patching programmatically through bundle_conda.py --patch-recipe (new addition in this PR) to override what we have in the stable release with the latest needs of our development version. Before this we were blindly taking the latest release as source of truth, potentially producing bad nightlies. The problem here is that our conda-forge releases come after the PyPI releases and the constructor installers.

Ok, but why don't we have a meta.yaml and/or [bundle-]environment.yml in this repo, keep it up to date with a test like @goanpeca proposes, and then come release we copy that over to the conda-forge recipe? Then we might not need shell scripts to convert cfg to yml?

Sure, we can do that as well.
I was trying to centralize metadata instead of adding more files, but if we have tests to tie things together, that might be enough. That said, I am unsure how we can test for perfect equality when the restraints are expressed with slightly different syntax (maybe error out when an operator outside the common subset is used?). I need to look deeper into that code Gonzalo shared, but it looks like a way of solving it.
So, just to make sure I got this right:

CI environments: Remove blocks from setup.cfg that require the shell snippet - these blocks will go into environment files directly.
Conda packages: Not sure about this one: are you suggesting that we also create a meta.yaml with the definitions we want instead of patching the feedstock? We will need to make sure that our copy of meta.yaml is more or less in sync with conda-forge's, but that should be ok. We basically change which copy is the source of truth: ours instead of conda-forge's.
Constructor dependencies: are these ok in setup.cfg or do you prefer we have a construct.yaml file as well? We need to add some fields dynamically depending on the type of build, so that's why we had it generated in the script first. This PR now adds the ability to define the dependencies in setup.cfg instead of using Python to write the dictionary directly.

In case we decide to add all these files, I'd suggest using resources/packaging/conda to store the metadata.

Yup, my feeling is that the cost of setup.cfg -> yaml conversion script, together with the inconsistencies right within a setup.cfg, is too high a price to pay to have all the metadata in a single file (an admirable goal indeed! :joy:).

CI environments: Remove blocks from setup.cfg that require the shell snippet - these blocks will go into environment files directly.

:+1:

are you suggesting that we also create a meta.yaml with the definitions we want instead of patching the feedstock?

I think so? :joy: I am not sure about this. Can you summarise our alternatives here? What do we do now? My impression is: on each release, we manually synchronise the values in the feedstock meta.yaml with the setup.cfg. In the meantime, nothing happens. But, this means that the nightlies are inconsistent — how are the nightlies built?
I'm also curious with the vision of how this will intersect with the idea of napari "distributions" for plugins, where we synchronise the packages that plugins will need to depend on for major packages like pytorch, tensorflow, cupy, etc. (Though I know that's out of scope for this PR :joy:)

Constructor dependencies: are these ok in setup.cfg or do you prefer we have a construct.yaml file as well?

This depends: can the tooling install them from the setup.cfg or do you need a yaml? Again, I would prefer not to shoehorn them into a single file if they are going to be shuttled off into the required format by some custom scripting.
Overall, I understand the concern with the proliferation of files, but this can be mitigated by e.g. having them in a folder, and/or having some documentation around the whole thing — which is indeed now rather complex, but I see the necessity for everything. :sweat_smile:

But, this means that the nightlies are inconsistent — how are the nightlies built?

Right now the workflow is the following:

Clone the conda-forge feedstock next to the napari repository. We end up with $GITHUB_WORKSPACE/napari-feedstock and $GITHUB_WORKSPACE/napari-source
Patch meta.yaml to make it use $GITHUB_WORKSPACE/napari-source instead of the latest release tarball. This is done with some shell/sed scripting. However, we were not doing anything about the runtime dependencies.
Run conda-smithy to rerender the feedstock so it catches the latest global configuration changes from conda-forge.

This PR changes step 2 in this way:

Instead of using sed to replace strings, we use a Python script based on souschef (tool to edit conda recipes)
We also patch the runtime dependencies with those stated in setup.cfg
We add a 3rd package output, napari-pinnings,  which simply lists a set of run_constrained dependencies, as stated in setup.cfg. This is what we need to control the potential dependency issues in our plugin ecosystem.

I didn't want to publish napari-pinnings to conda-forge because it adds no value to that community and we don't want to re-release napari builds every time we patch the pinnings. Instead, we will only publish it to our own napari channel in anaconda.org. This is why I used this PR to centralize all the metadata, because I was going to use souschef anyway to add this new output package.

This depends: can the tooling install them from the setup.cfg or do you need a yaml? Again, I would prefer not to shoehorn them into a single file if they are going to be shuttled off into the required format by some custom scripting.

It doesn't have native support for setup.cfg, but the massaging needed is equivalent to what bundle.py was doing. Each section is a block of strings, so we essentially parse that block of strings into separate lines, removing/keeping comments as necessary. We then use the resulting list to generate the construct.yaml file. This file however needs different fields across platforms (e.g. conda channels are different for arm64 due to the availability of pyqt/pyside packages).

I know this feels like a lot, because it is 😂  We are trying to standardize metadata usage across ecosystems with minimum maintenance, which will require some amount of either in-house scripting or reliance on external, experimental tooling. We need to find a compromise between "metadata-across-files hell" and "single-file with non-trivial scripting". The way I see it, it's feels easier to reason about problems when there are less moving pieces involved. Adding more files to the repo increases the amount of files I need to think about maintaining. If everything is in setup.cfg, I don't need to know that conda build wants a meta.yaml, conda create needs environment.yml and constructor requires construct.yaml.
This the reason I went for "all-things-in-setup.cfg": I find it simpler to think of a single file for metadata definitions if we ever run into packaging problems.
I am not sure if developers will go and read the documentation when they find a problem or something they don't understand. Before they get to fix that dependency problem, they will have to understand all the files involved, and the different tools. (As a matter of fact, a part of this conversation is already covered in the current docs, so I wonder if they are serving the intended purpose).
I am happy to adjust the foundational principles of our metadata if that makes sense for everyone. I am comfortable with both a single-file approach and a multi-file one, but I'd like to know what other people, maybe less familiar with the conda ecosystem, think about this issue.
PS: We could also think of migrating from setup.cfg to pyproject.toml for better parsing... but that might be a can of worms. If editable installs are an issue, flit has support for it already, but setuptools_scm doesn't play nicely with it... aaa the wonders of packaging ✨ 📦

If everything is in setup.cfg, I don't need to know that conda build wants a meta.yaml, conda create needs environment.yml and constructor requires construct.yaml.
This the reason I went for "all-things-in-setup.cfg": I find it simpler to think of a single file for metadata definitions if we ever run into packaging problems.

I get this in general, but one thing that might/does happen is that you run the build and you get an error, and the error references a line in a file (e.g. meta.yaml) that doesn't exist, and then you can go crazy figuring out how it gets made and how that went wrong. I'm getting flashbacks to sphinx-gallery build failures for example.
Basically, the setup.cfg is, I think, a very leaky abstraction.
Also, if I google "construct.yaml", I get taken to the constructor README, whereas if I google "setup.cfg conda_installer section" I will get nothing. (Though at some point I might get the right page on napari.org, yes ;)
But, it's definitely a tradeoff, I don't feel strongly enough to block this, but neither do I feel confident enough to approve. 😂 I agree with you, it'd be good to have more takes here. I'd particularly like to hear what @sofroniewn and @tlambert03 think.
For either solution, the ideal case for me is that we get the base dependencies from the pip dependencies, and update them in some declarative way that might include package renaming, e.g. a section like:
conda-package-names:
  - pyqt5: pyqt
conda-additional-deps:
  - python.app

I understand that this would be more engineering effort and I'm totally happy to punt on it, but I like to write down my ideals somewhere before we go down a compromise road. 😊

I'd particularly like to hear what @sofroniewn and @tlambert03 think.

I had a chat with this very generally with @nclack who seemed to favor the single file with custom build script approach in general under the rationale that it can be easier to maintain. Maybe he can give this a look over and weigh in on the PR

I suggest taking the approach from the minimal dependencies test and creating a python script that will be producing conda dependencies from python dependencies. As I understand there are only a few packages that need to be renamed so it could be handled with s small dict?

Thanks everyone for your inputs! There are a number of questions on the table we would need to address before deciding what to implement. Let me summarize:

Unified setup.cfg versus tool-specific files. If we don't like the supporting scripting (and that's fine), we will need the following files plus a test that ensures everything is in sync (not trivial, in my opinion, given the slightly different syntaxes and package names). Files:

Environments to provide the tooling needed in this CI: two different environment.yml files (although we can merge them in a single, larger environment if people prefer that).
Recipe: in principle, only the meta.yaml file, but we need to clone the full feedstock to have conda-forge compatible builds in our pipeline.
Installer: construct.yaml, which would need to be modified in some instances of the script to accommodate for platform-specific options. This is problematic because selectors in conda- world were implemented as comments (sigh), so round-trip parsing is lossy :/ That's why we build it programmatically now, inserting the packages and channels from setup.cfg.

What to do with the contents of napari-pinnings. We are patching conda-forge's meta.yaml to add a completely new output to the recipe. This might be too much for a "patch", depending on how we look at it. Its contents will also be key in the maintenance of the plugin ecosystem, so maybe it deserves a more prominent place. This might have a different release cadence than napari itself, so maybe we want it in a different package with its own recipe? Since this package will be used only internally in the installer, I don't think it should be posted to conda-forge, so we would keep it in our organization. Do we want to create a feedstock repo for it? 🤷

Since this package will be used only internally in the installer, I don't think it should be posted to conda-forge, so we would keep it in our organization.

I dunno, I kinda like the idea of having it in conda-forge so that pythonistas helping bundle users can create/troubleshoot in a proper conda-env of their own? Though I guess they can just add our channel in that situation?

Though I guess they can just add our channel in that situation?

Yes, the idea is to post this to our napari channel only. The bundle installation will have napari on its channel lists, followed by conda-forge. To reproduce, they can do conda create -n test -c napari -c conda-forge ....

I would like to link this issue  #4395, where I directly ask for such metapackage.

I feel rather unqualified to make much of a comment here.  I don’t have many strong opinions, and am  more or less happy to defer to whatever @jaimergp and @goanpeca think in this realm.  So with that caveat, my very weak thoughts here are:

i don’t mind having additional files for metadata.  If there are standard places that these metadata should be (such as a constructor.yaml or something else), then my first inclination would be to put them there directly (even if it means one more root file).  If they also supported setup.cfg, then great, but it does feel a bit weird to add it there just a place to consolidate.  (If anything, I guess I’d go for pyproject as the place that one day we might really consolidate everything). But very minor stuff
i also agree it’d be lovely not to have to add runtime deps in two places, but see @jaimergp’s point that deps are slightly different in conda world and pip, so one way or the other, some special casing needs to be done.

All told, this feels like a mostly internal decision that could be modified in the future, without breaking anything, right?

All told, this feels like a mostly internal decision that could be modified in the future, without breaking anything, right?

Yes, this doesn't affect the end product. No matter how we organize the raw data, the building tools will end up receiving the same inputs, and hence will produce the same outputs.
I don't see constructor or conda supporting pyproject.toml configs any time soon, so I guess we'll go for more explicit files under resources/packaging or something like that. We might need to patch parts of them depending on the case, though, but it can be done.

Yes, this doesn't affect the end product. No matter how we organize the raw data, the building tools will end up receiving the same inputs, and hence will produce the same outputs.

Ok i think we can go ahead and merge this then. I think we've had a lot of folks weigh in and going with what has been implemented makes sense. If this causes us problems in the future we can change without effecting the end experience
@jaimergp can you fix the merge conflict - thanks!

Conflicts are gone but that typing issue is still there.

Merge in main

Following https://napari.org/dev/naps/2-conda-based-packaging.html do we want to close this PR or switch over to draft? it's got a number of approves, so i don't want us to merge by mistake. @jaimergp what you recommend?

This will be taken over to napari/packaging as part of the ongoing migration, so no merge needed here! I marked it as draft just in case.


Facing issue when running "Flutter doctor" command in cmd

`Failed to find the latest git commit date: VersionCheckError: Command exited with code 128: git -c
log.showSignature=false log HEAD -n 1 --pretty=format:%ad --date=iso
Standard out:
Standard error: fatal: detected dubious ownership in repository at 'C:/src/flutter'
'C:/src/flutter' is owned by:
        'S-1-5-32-544'
but the current user is:
        'S-1-5-21-425165268-2986998246-3957258218-1001'
To add an exception for this directory, call:

        git config --global --add safe.directory C:/src/flutter

Returning 1970-01-01 05:30:00.000 instead.`

Thanks for the report @mukulchauhan3
Based on the error log, it seems to be related to the permission, as it says Standard error: fatal: detected dubious ownership in repository at 'C:/src/flutter'
The tool is correctly identifying what could be the cause of the issue, as it shows the current user and the permission owner, so double check the permission setup and see if correct user is logged in. Also try to use the command as suggested by the tool git config --global --add safe.directory C:/src/flutter and see if it helps.
I am going ahead and closing this, since this could be related to the way permissions are setup in your system and tool identified that and suggested the fix. If you still get the same error after trying with the fix, write in comments and I'll reopen it.


Resetting the Password for Logging In to a Linux ECS

Issue on page:        https://github.com/opentelekomcloud-docs/elastic-cloud-server/blob/main/umn/source/passwords_and_key_pairs/passwords/resetting_the_password_for_logging_in_to_a_linux_ecs.rst
The mentioned script on step one is nowhere to be found.

Thank you, we will check this infromation


Scope is not applied when model is instantiated via dependency injection within controller

The tenant scope is not applied when instantiating the model as follows:
class OrderController extends Controller
{
    protected $order;

    public function __construct(Order $order)
    {
        $this->order = $order;
    }

...

but...
Order::all() // works fine

This is not a huge issue, when you know this is the case, but does anyone know why or of any work arounds to it?

Maybe you can move the      \Illuminate\Routing\Middleware\SubstituteBindings::class away from the global middleware and set it after your Landlord middleware.


Add miniCRAN binaries for macOS

They should be there unless you're installing on Windows. On Windows you should get a warning that they can't be provided. If this doesn't reflect the usage where they are missing we can dig into it more.

Was an outdated carpentries offline image, they are there now!


Support for table names longer than 64 characters

Example panic:
thread 'thread 'thread 'tokio-runtime-workertokio-runtime-workerthread 'thread 'thread 'tokio-runtime-worker' panicked at 'thread 'thread '' panicked at 'thread 'thread 'tokio-runtime-workerthread 'tokio-runtime-workerthread 'tokio-runtime-worker' panicked at 'DatabaseTable::new: Table name `data__W3RdfSyntaxNsType__PropertyDirect_P1947__W3Owl_DatatypeProperty` has more than 64 characterstokio-runtime-workertokio-runtime-workerDatabaseTable::new: Table name `data__WOqualifierValueNormalized__P1947__PropQualValueNormalized_P1947` has more than 64 characterstokio-runtime-workertokio-runtime-worker' panicked at 'tokio-runtime-worker' panicked at 'tokio-runtime-worker' panicked at 'DatabaseTable::new: Table name `data__WOdirectClaimNormalized__P1947__PropertyDirectNormalized_P1947` has more than 64 characters', ' panicked at '' panicked at '', ' panicked at '' panicked at 'DatabaseTable::new: Table name `data__W3RdfSyntaxNsType__PropertyReferenceValue_P1947__W3Owl_ObjectProperty` has more than 64 characters' panicked at 'DatabaseTable::new: Table name `data__W3RdfSyntaxNsType__PropQualValue_P1947__W3Owl_ObjectProperty` has more than 64 characters' panicked at 'DatabaseTable::new: Table name `data__W3RdfSyntaxNsType__PropertyStatement_P1947__W3Owl_DatatypeProperty` has more than 64 characters', src/database_table.rsDatabaseTable::new: Table name `data__W3RdfSyntaxNsType__PropQualValueNormalized_P1947__W3Owl_ObjectProperty` has more than 64 charactersDatabaseTable::new: Table name `data__W3RdfSyntaxNsType__PropertyDirectNormalized_P1947__W3Owl_ObjectProperty` has more than 64 characterssrc/database_table.rsDatabaseTable::new: Table name `data__W3RdfSyntaxNsType__PropertyReference_P1947__W3Owl_DatatypeProperty` has more than 64 charactersDatabaseTable::new: Table name `data__W3RdfSyntaxNsType__PropertyStatementValue_P1947__W3Owl_ObjectProperty` has more than 64 characters', DatabaseTable::new: Table name `data__WOreferenceValueNormalized__P1947__PropertyReferenceValueNormalized_P1947` has more than 64 characters', DatabaseTable::new: Table name `data__W3RdfSyntaxNsType__PropertyReferenceValueNormalized_P1947__W3Owl_ObjectProperty` has more than 64 characters', src/database_table.rs:', ', :', ', src/database_table.rs', src/database_table.rs', src/database_table.rs:21src/database_table.rssrc/database_table.rs21src/database_table.rssrc/database_table.rs:src/database_table.rs:src/database_table.rs:21::::::21:21:21:132121132121:21:21:13
::
::13:13:13
13131313
13
13

I would love to but MySQL/MariaDB does not agree with me. Maybe I'll make it a config option?


Implement identical logic using Vite

This removes the VFS fonts because they fail to build with Vite (and likely also with Rollup, which Vite uses under the hood).
See https://github.com/bpampuch/pdfmake/issues/2654 for some potential ideas to resolve this.

This is great, thank you @fwouts ! I could not decide which of rollup, esbuild or vite to use, so I am glad you made a choice! No problem for the pdf fonts, really not a problem here - my focus here is just to learn how to bundle the library.
One more question. I see that vite-plugin-singlefile produces a single HTML file, that's almost what I need, but do you think instead we could bundle a single JS file from which I could import e.g. import {DataTable, jQuery as $} from "bundle.js"? I want to keep that import separate from data and dt_args that are provided at a later stage.

Yes! All you need is to remove the single file plugin, and it will do exactly that 😁

Yes! All you need is to remove the single file plugin, and it will do exactly that 😁

Almost there! Still two points that I would like to address when time permits:

The data that is defined in the HTML file currently goes to the bundled .js file. I would need to keep it appart and bundle just the ./src/dt_with_buttons.js file. I want to be able to replace import {DataTable, jQuery as $} from "./src/dt_with_buttons.js"; (which has external dependencies) in the original HTML with import {DataTable, jQuery as $} from "bundle.js"; (self contained, so I can actually import from its base64 representation).
The bundle file is called e.g. index-0M51yzQc.js. I would need to know or even set the bundle file name in advance.

I have had some success with esbuild in (#2) - my only concern is that I could not find how to import from the bundle, so I am currently exporting through window - not sure if there is a better way to do so?

Thanks @fwouts for fixing the esbuild PR! I've taken that other PR (#2) instead as it is closer to what I will be doing in itables.


BUG - employee page does not refresh when a new user is added

The employee table does not update automatically when a new user is added.
We probably want to modify our staff/create endpoint to return an updated list of staff and use it to refresh the table.

I think what we do here is add the user to the app state when we send the post request to the back end. That means the front end doesn't need to wait to receive the same data again and can just update its own state.
So we can add another reducer:
      state.value = state.value.concat(action.payload);
    },```

And then fire this action when we add a staff member:

```  post(STAFF_CREATE_URL, token, staff)
    .then((response) => response.json())
    .then((response) => dispatch(add(response)))
    .catch((err) => toastr.error(err));```

As long as the front-end can do enough verification to ensure that what is entered _should_ be correct, this way should work fine. If anything did go wrong, refreshing the page will show what the database thinks is true.

I think what we do here is add the user to the app state when we send the post request to the back end. That means the front end doesn't need to wait to receive the same data again and can just update its own state.
So we can add another reducer:
add: (state, action: PayloadAction<StaffData>) => {
      state.value = state.value.concat(action.payload);
    },

And then fire this action when we add a staff member:
post(STAFF_CREATE_URL, token, staff)
    .then((response) => response.json())
    .then((response) => dispatch(add(response)))
    .catch((err) => toastr.error(err));

As long as the front-end can do enough verification to ensure that what is entered should be correct, this way should work fine. If anything did go wrong, refreshing the page will show what the database thinks is true.

Adding dispatch inside then already does the verification.
The problem of this approach is that add user modal does not create StaffData, but CreateStaffData, which are similar but not identical.
For example, StaffData contains an id which is auto-generated by the database.
What happens if someone adds and deletes a user without refreshing the page? We would need to rewrite everything to pass e.g. an e-mail instead of user id.

Sorry, I got confused and edited my post above. I meant use the single response from the database to just add that Staff member to the state, so it will have the database information.

It feels strange to just add the user to the state yourself, does this not violate single source of truth? also Causes issues if we have  server side paging later

It's just another way of doing it, I guess since we aren't working with a lot of data it would be fine to perform a GET request after adding a new user.
https://uxplanet.org/optimistic-1000-34d9eefe4c05

I guess the question is what do we want to happen if the request fails for whatever reason (e.g. connectivity issues?).
As a user, if I saw a table updated I would assume that the request processed successfully and I can safely navigate away from the page. We would need to add some visual indicator that the request has not completed yet and when it's done, we'd have to update the table with the response data anyway.
So I think we need to modify the endpoint to respond with the updated staff data anyway.

If the endpoint returns the single user we can still have this behaviour. If the backend doesn't successfully save the staff member then it won't return the staff object so nothing will be added to the front end. It will probably return a 400 which we can then grab and throw a nice toastr message perhaps?


[FEAT] Create Team CTA

Linked Issue(s)
#529
#537
Acceptance Criteria fulfillment

[x] Add a button that redirects to the team page with create query
[x] Consume the query in the team Page and show create team component

Proposed changes (including videos or screenshots)
Screencast from 2024-09-09 13-24-32.webm

Hey @e-for-eshaan
I am implement the CTA button
Please take a look

asymmetric design, looks a bit off
suggestions:

make the button to be full width of the selector-popover
make padding, margins and spacings to be uniform (above the button)
use <Button variant="outlined"/>. My hopes are that it might look better than the current design

asymmetric design, looks a bit off suggestions:

make the button to be full width of the selector-popover
make padding, margins and spacings to be uniform (above the button)
use <Button variant="outlined"/>. My hopes are that it might look better than the current design

Hey, @e-for-eshaan Looks Good now?

Hey @e-for-eshaan  I have also solved #537  in this PR
In this PR as well There Is some type assertion Because  payload.team was unknow

yes this happens when consuming the response from dispatch pomise.
use this as the .then callback
(res: any) => {
if(res.meta.requestStatus !== 'rejected')
/*...your code...*/
}

Hey @e-for-eshaan  You mean to handle this call inside .then right?
I am already doing it inside that even here the res.payload type exist but .team in unknown

we typecast it to any
(res: any) => {}

that's what i was referring to in previous comment

okay so we are not sure about response type here

@e-for-eshaan  I have made the changes  and here I didn't use the requestStatus check because we already had a check and where we returned early

cool, i want you to check for data now
console.log a singleTeam when selecting from the teams selector
and console.log the response that you get after creating a team
are they the same type of object? does it need any more/fewer keys?

Sure Let me check last time I check it was same but lets see how  it's different from other case

@e-for-eshaan  This is what we get when we use the selector to update team

this is what we get from response team

only difference is manager_id here

also you can checkout complete working in the updated video above

also you can checkout complete working in the updated video above

I added the is_deleted  in our response as well and obviously its just created so its not false

@e-for-eshaan Please take a look let me know if anything else left to do

it's not okay to use assign selectedTeam in such an unsafe manner, might get troublesome later since it violates some basic assumptions.
How to approach this?

we have to find the team from the team-map we have in the redux state.
const teamMap = useSelector((state) => state.team.teams)

so now, the events that transpire will be:

create team
wait for the call to finish (and be successful). get this response's teamId (c-id)
wait for the call that refreshes the teams maps
find the c-id w.r.t this fresh team-map

feel free to ask more questions!

Hey @e-for-eshaan How can we wait for that its not a asyn call right ?

How can we wait for that call that refresh the teams it doesn't return promise right ?

Hey @e-for-eshaan  I understood what we want to do here But I am not able to get the Updated Teams Map can you share me how can we get that ?

fetchTeamsAndRepos: this seems to be the function refreshing the teams-map
edit this function to return a promise-response (async await)
use a .then on this function
consume the teams payload for this function
definitely add checks on the requestStatus every time, whenever consuming directly from dispatch promises

Awesome I was doing the same thing last night I basically tried different ways thanks for suggestion @e-for-eshaan  I will suggested changes.

Have a look @e-for-eshaan

jagged alignment, use <FlexBox centered>...</Flexbox>

Have a Look @e-for-eshaan

This is how it looks with more than 4 teams

Can you update the final video?

Can you update the final video?

Updated

Good stuff, approving! 🎉

Hey @e-for-eshaan I made the requested changes and also solved issue
Thanks man 😊🔥

Good stuff, approving! 🎉

Thanks man 😊 🔥

Can we get this merged?


No alert/warning on clicking search/create ride when done without login

Add alert for clicking search/create ride button when done without user login

https://github.com/NCSU-SE-2024/PackTravel_v2/pull/2


Multiple ssrLoadModule calls can return different copies of internal modules

[X] Read the docs.
[X] Use Vite >=2.0. (1.x is no longer supported)
[X] If the issue is related to 1.x -> 2.0 upgrade, read the Migration Guide first.

Describe the bug
When doing server side rendering with ssrLoadModule, loading more than one module and then using them together can break, because the modules returned by ssrLoadModule can use different copies of internal dependencies.
This breaks React specifically, because if two different modules are loaded by ssrLoadModule that use two different Reacts, the hooks system breaks and React gives this message:
Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem.
    at resolveDispatcher (/Users/airhorns/Code/vite/node_modules/react/cjs/react.development.js:1476:13)
    at Object.useContext (/Users/airhorns/Code/vite/node_modules/react/cjs/react.development.js:1484:20)
    at useMDXComponents (/Users/airhorns/Code/vite/node_modules/@mdx-js/react/dist/cjs.js:126:33)
    at MDXProvider (/Users/airhorns/Code/vite/node_modules/@mdx-js/react/dist/cjs.js:138:23)
    at processChild (../../../../../node_modules/react-dom/cjs/react-dom-server.browser.development.js:3352:13)
    at resolve (../../../../../node_modules/react-dom/cjs/react-dom-server.browser.development.js:3269:4)
    at ReactDOMServerRenderer2.render (../../../../../node_modules/react-dom/cjs/react-dom-server.browser.development.js:3752:21)
    at ReactDOMServerRenderer2.read (../../../../../node_modules/react-dom/cjs/react-dom-server.browser.development.js:3689:28)
    at Object.renderToString (../../../../../node_modules/react-dom/cjs/react-dom-server.browser.development.js:4297:26)
    at /Users/airhorns/Code/vite/packages/playground/ssr-react/server.js:61:38

Reproduction
Here's a small change to the ssr-react playground app that demonstrates this issue: https://github.com/vitejs/vite/compare/main...airhorns:ssr-module-mismatch . Instead of loading one module that does the rendering inside it, we require ReactDOMServer with one ssrLoadModule call, and then the app we want to server-side-render with a second one. React throws when using that ReactDOMServer copy to run the app if there's a module inside the app that uses React hooks.
Run yarn dev in the packages/playground/ssr-react package to see the error above.
Discussion
I realize this isn't really the intended use of ssrLoadModule -- the examples all load one main function that then does all the work inside it. That has worked fine for me in my experience where within a module the same copy of internal dependencies is used. But, is it reasonable to expect that multiple calls to ssrLoadModule should be re-using the same module graph internally? My amateur reading of the code suggested yes. If that isn't reasonable, I can prepare a docs PR that makes this caveat known.
The reason I would want to load ReactDOMServer once and then load other modules after that is doing a next.js style server side page renderer that renders many entrypoints. It'd be nice to load the common bits once instead of n times, and then load only the entrypoints the developer accesses as they are accessed during development.
System Info

vite version: f7466d1d095852db998c85c0370fe2671a1f06fd
Operating System: Darwin inspector 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec  2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64 x86_64
Node version: v15.7.0
Package manager (npm/yarn/pnpm) and version: yarn 1.22.10

ReactDOMServer is auto externalized and never loaded more than once.

This happens to me with React itself as well -- not just ReactDOMServer Is it also auto externalized? See the error message in the ticket. If both of those were true, I wouldn't see that error message would I?

@yyx990803 apologies for the ping but I think there is more to this issue! What I am seeing is different copies of react itself returned from different ssrLoadModule calls, so despite ReactDOMServer or react being auto-externalized I think there is still a gotcha here where ssrLoadModule has importantly different semantics than require.  I think we should document that if it's intentional, or fix a bug in the module caching code. It seems like the module graph's intention is to cache and return the same copy of a module if possible, right?

Can you provide a minimal standalone repro?

You can see a minimal one here: https://github.com/vitejs/vite/compare/main...airhorns:ssr-module-mismatch . I removed any mdx stuff from that -- the issue appears as soon as you load react-dom/server separately from react in two ssrLoadModule calls, and then use any React hook. I know vite isn't a react specific framework (and that you probably don't wanna plow all your time into making react work great!) but I do think this is a specifically common thing that React devs might wanna do that it's worth looking into this a bit.
If you look closely at the error you will see two different paths to two different react modules:
Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem.
    at resolveDispatcher (/Users/airhorns/Code/vite/node_modules/react/cjs/react.development.js:1476:13)
    at Proxy.useState (/Users/airhorns/Code/vite/node_modules/react/cjs/react.development.js:1507:20)
    at App (/Users/airhorns/Code/vite/packages/playground/ssr-react/src/App.jsx:18:36)
    at processChild (../../../../../node_modules/react-dom/cjs/react-dom-server.browser.development.js:3352:13)
    at resolve (../../../../../node_modules/react-dom/cjs/react-dom-server.browser.development.js:3269:4)
    at ReactDOMServerRenderer2.render (../../../../../node_modules/react-dom/cjs/react-dom-server.browser.development.js:3752:21)
    at ReactDOMServerRenderer2.read (../../../../../node_modules/react-dom/cjs/react-dom-server.browser.development.js:3689:28)
    at Object.renderToString (../../../../../node_modules/react-dom/cjs/react-dom-server.browser.development.js:4297:26)
    at /Users/airhorns/Code/vite/packages/playground/ssr-react/server.js:64:38

ReactDOMServer loaded from the first ssrLoadModule call is using a relative path like that, which makes me think that it is ignoring some auto-externalization that might be happening, whereas the second ssrLoadModule call that loads an app to render in is maybe respecting it?
I am struggling to reproduce with something other than react as well -- this works fine if I set up a module with a symbol, and then import it from two other modules, and then use ssrLoadModule to load each of those two modules individually. They both export the exact same symbol, so that's good.

Ugh that's just wrong usage. ReactDOMServer is a Node module and should be loaded with require(). ssrLoadModule is for loading client-oriented source code in Node.


Eliminate ternary if statement

I'll approve this but the original code seems to work on my docker. Not sure what's going on but this doesn't hurt performance or readability so it is not worth investigating...

Agreed, this is likely a tooling issue.  The original implementation should be entirely appropriate and functional.


added the ability to set a filter on live streaming so values only wi…

This adds the ability to filter live log values bases on this. This is handy when running with small step sizes since it almost kills the app to draw the graph

You need the latest COE 0.1.13-SNAPSHOT

Does this crash with prior versions of the COE?

yes this is not backwards compatible. I changed the COE to not require all properties in the future

If it's not backwards-compatible, we need to bump the app to 3.0.0.
Other than that, I'm fine with this.


[SPARK-24677][Core]Avoid NoSuchElementException from MedianHeap

What changes were proposed in this pull request?
When speculation is enabled,
TaskSetManager#markPartitionCompleted should write successful task duration to MedianHeap,
not just increase tasksSuccessful.
Otherwise when TaskSetManager#checkSpeculatableTasks,tasksSuccessful non-zero, but MedianHeap is empty.
Then throw an exception successfulTaskDurations.median java.util.NoSuchElementException: MedianHeap is empty.
Finally led to stopping SparkContext.
How was this patch tested?
TaskSetManagerSuite.scala
unit test:[SPARK-24677] MedianHeap should not be empty when speculation is enabled

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can you add a test to check if no exception thrown in that condition with this patch?

@maropu @cloud-fan @squito
Can you trigger a test for this?
This is the exception stack in the log:
ERROR Utils: uncaught error in thread task-scheduler-speculation, stopping SparkContext
java.util.NoSuchElementException: MedianHeap is empty.
at org.apache.spark.util.collection.MedianHeap.median(MedianHeap.scala:83)
at org.apache.spark.scheduler.TaskSetManager.checkSpeculatableTasks(TaskSetManager.scala:968)
at org.apache.spark.scheduler.Pool$$anonfun$checkSpeculatableTasks$1.apply(Pool.scala:94)
at org.apache.spark.scheduler.Pool$$anonfun$checkSpeculatableTasks$1.apply(Pool.scala:93)
at scala.collection.Iterator$class.foreach(Iterator.scala:742)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1194)
at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
at org.apache.spark.scheduler.Pool.checkSpeculatableTasks(Pool.scala:93)
at org.apache.spark.scheduler.Pool$$anonfun$checkSpeculatableTasks$1.apply(Pool.scala:94)
at org.apache.spark.scheduler.Pool$$anonfun$checkSpeculatableTasks$1.apply(Pool.scala:93)

ok to test

Test build #92631 has started for PR 21656 at commit 55ddbeb.

cc @jiangxb1987

Test build #92631 has finished for PR 21656 at commit 55ddbeb.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92631/
Test FAILed.

Merged build finished. Test FAILed.

I assume this is really that it isn't updating successfulTaskDurations?  MedianHeap is a collection, can you please update description and title to be more explicit

In this case one of the older stage attempts (that is a zombie) marked the task as successful but then the newest stage attempt checked to see if it needed to speculate. Is that correct?
Ideally I think for speculation we want to look at the task time for all stage attempts. But that is probably a bigger change then this.  If we aren't doing that then I think ignoring it for speculation is ok.   Otherwise how hard is it to send the actual task info into here so it could use the real time the successful task took?

Ideally I think for speculation we want to look at the task time for all stage attempts. But that is probably a bigger change then this

yeah I agree, on both points.  One thing which is a little tricky is that you probably want to make sure you're only counting times from different partitions -- you might times from the same partition from multiple attempts, but that shouldn't count.  (or maybe we don't really care that much as its just a heuristic anyway ...)

Test build #92817 has started for PR 21656 at commit d8fdceb.

Ok what did we decide on the time then?  I would say for now either ignore or send down the real time.
@cxzl25 How hard is it to send the actual task info into here so it could use the real time the successful task took?  At a glance it doesn't look to hard to add in the additional information into the function calls to pass it into markPartitionCompleted

@tgravescs
This is really not difficult.
I'm just not sure if we want to ignore or send down the real time.
Now I have submitted a change, use actual time of successful task.

Test build #92820 has started for PR 21656 at commit 1c1df5c.

The changes LGTM

Test build #92817 has finished for PR 21656 at commit d8fdceb.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92817/
Test PASSed.

Test build #92820 has finished for PR 21656 at commit 1c1df5c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92820/
Test PASSed.

@squito  are you ok with this approach?

+1

lgtm

merged thanks @cxzl25


Adds Parent category in category details page

Title (required)

Fixes #1642  (Add a category details page in app)
Fixes #1699 ("No media" even though category contains pictures)

Description (required)

API added for receiving Parent categories of a particular category
Reused SubcategoryList fragment for getting parent category list using isParentCategory boolean
Fixed edge case issue for not showing images

Tests performed (required)
Manually Tested on API 25 & Moto G5S+, with ProdDebug  variant
Screenshots showing what changed (optional)

Codecov Report

Merging #1701 into browse-commons-via-app will decrease coverage by 0.02%.
The diff coverage is 0%.

@@                    Coverage Diff                    @@
##           browse-commons-via-app   #1701      +/-   ##
=========================================================
- Coverage                    3.59%   3.57%   -0.03%
=========================================================
  Files                         165     165
  Lines                        8309    8358      +49
  Branches                      757     764       +7
=========================================================
  Hits                          299     299
- Misses                       7993    8042      +49
  Partials                       17      17

Impacted Files
Coverage Δ

.../nrw/commons/category/CategoryDetailsActivity.java
0% <0%> (ø)
:arrow_up:

...rw/commons/mwapi/ApacheHttpClientMediaWikiApi.java
3.98% <0%> (-0.2%)
:arrow_down:

.../nrw/commons/category/SubCategoryListFragment.java
0% <0%> (ø)
:arrow_up:

.../fr/free/nrw/commons/category/GridViewAdapter.java
0% <0%> (ø)
:arrow_up:

...w/commons/category/CategoryImagesListFragment.java
0% <0%> (ø)
:arrow_up:

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 5f77ba9...98ed7db. Read the comment docs.


Adding index recovery priority to .opendistro_security index

As an enhancement, I would like to suggest that the out of the box the .opendistro_security index had priority for recovery due to how critical it is.
(https://www.elastic.co/guide/en/elasticsearch/reference/current/recovery-prioritization.html)

Duplicate of #534


Properly detect --test command-line argument

Do not prematurely parse anything which begins with --test to run doctest. This allows other commands to be run, such as using testing/debugging tools for GDScript with --test-gdscript (as seen in #41074) or other custom arguments.

I would say it's a bug fix actually. Without this, you could pass a command like --testasdasdasd and it would run doctest. 😃

Thanks!


[FEATURE] Handle allowable 0s in marginal controls

Is your feature request related to a problem? Please describe.
When the user passes aggregates to the ipfn class that contain any 0-valued elements the algorithm performs as expected but prints a warning to the console. This can become excessive when running many IPFs.
ipfn\ipfn.py:146: RuntimeWarning: invalid value encountered in scalar divide if abs(m_ijk / ori_ijk - 1) > max_conv:

Describe the solution you'd like
import numpy as np
from ipfn import ipfn

m = [[40, 30, 20, 10], [35, 50, 100, 75], [30, 80, 70, 120], [20, 30, 40, 50]]
m = np.array(m)
xip = np.array([150, 0, 400, 150])
xpj = np.array([200, 300, 400, 100])

aggregates = [xip, xpj]
dimensions = [[0], [1]]

IPF = ipfn.ipfn(m, aggregates, dimensions, convergence_rate=1e-6, verbose=0)
m = IPF.iteration()

If verbose=0 the RuntimeWarning should not be printed to the console. This will require edits to lines 146 and 246 in ipfn/ipfn.py.
Describe alternatives you've considered
Could potentially implement a messages flag separately from the verbose input but many other libraries use verbose to suppress messages printed to the console and/or a log file.
Additional context
These messages when printed to the console or a log file can become excessive when running many IPFs.

First commit requires Python > 3.11 which is not necessarily a reasonable requirement. Change to solution that allows for older version of Python.


add go modules support

Fixes #1547

Thank you for this PR.
I'll have a look at gomod soon, however, before that I'm planning some major refactoring, which will also effect the external dependencies. Therefore I'm going to close this PR.


Search Optimization

site\src\component\SearchModule\SearchModule.tsx
Search optimization

Currently sending a query request for every input change
Goal is to have only one query request pending
Use setTimeout/clearTimeout to keep track of pending query request

Looking at the code, it seems like this has already been implemented but the TODO comment was never deleted.


[V5] Error loading wave source?

I previously had some problems with missing modules but I was able to re-install them properly but I get this message now:
Running HP2-4BAND-3090_4band_1
loading model... done
loading & stft of wave source... Traceback (most recent call last):
File "inference.py", line 344, in
main()
File "inference.py", line 157, in main
wave, _ = librosa.load(args.input, bp['sr'], False, dtype=np.float32, res_type=bp['res_type'])
TypeError: load() takes 1 positional argument but 3 positional arguments (and 2 keyword-only arguments) were given
Any ideas?

Please update to version 5.2.0 using the Windows installer provided on the main page.


Fix cudnn Dropout reproducibility

Fix https://github.com/apache/incubator-mxnet/issues/15662
This will replace #16532 with an alternative solution.
Please refer to the discussion in  https://github.com/apache/incubator-mxnet/pull/16532#discussion_r339268855

Added GetSeed() in GPU random resource, it's similar to CPU version.
During cudnn dropout, check whether random seed has been changed and reset cudnn dropout descriptor's seed if random seed changed.

Benefit:

This avoided generating a random int (tensor on gpu) on GPU, copy to CPU and and pass it to cudnnDropoutGetStatesSize.
get the seed from gpu random resource is fast, we can afford to do it every forward.

Drawback:
Will be affected by https://github.com/apache/incubator-mxnet/issues/7410, by default mxnet's random seed is fixed.

@DickJC123 @ptrendx could you help take a look again? Thanks

@DickJC123 @ptrendx Can you please review this PR once again? Thanks!

@roywei Could you please rebase and update this PR? Thanks!

@roywei with CI issue fixed. let's rebase to include the fix. Thanks!

restarted CI jobs. @roywei can you get your PR merged once they pass CI

@access2rohit without rebasing, the fix #17962 won't be included [for windows-gpu]

@ChaiBapchya @access2rohit  Rebased! Thanks!


yiiActiveForm not working when clientValidation or dynamic fields is OFF

I have a form that I add a form dynamically. so basically its a collection input, however I want to validate it using the yiiActiveForm but it was not working because it was dependent when the clientValidations is set to true
// add error
$('#contact-form').yiiActiveForm('updateAttribute', 'contactform-subject', ["I have an error..."]);

// remove error
$('#contact-form').yiiActiveForm('updateAttribute', 'contactform-subject', '');

If you need yii.activeform.js registered in your page, register asset yii\widgets\ActiveFormAsset in it.

Up

What do you mean by "was dependent"?

try to do
'enableClientValidation' => false,

and do $('#contact-form').yiiActiveForm('updateAttribute', 'contactform-subject', ["I have an error..."]);
you will see that you can't do that anymore but when you turn on the enableClientValidation => true, it will work as fine.

Well, that is expected. updateAttribute is part of client validation you've disabled.

could be?
but what if you have a special field that you need to check in server side and manually use ajax() like calling some 3rd party API and if its fail. you need to update the field and you can't maximize the usage of yiiActiveForm('updateAttribute')

If you want client validation you have to keep it enabled.

ok but would it be better if you can maximize everything even the clientValidation is turn off. isnt it?

No.


On save handlebars plugin template reverts to previous version of the code.

On save handlebars plugin template reverts to previous version of the code.
How to reproduce the bug

Modify a handlebars template
Save it (do not go to dashboard)

Expected results
Keep the modifications made.  The modifications are saved, It saves the template
Actual results
Old code displayed
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
(please complete the following information):

browser type and version:  Chrome (Version 111.0.5563.147 (Official Build) (64-bit))

superset version: docker hub latest (as of 4/6/23)

python version:

node.js version:

any feature flags active:
HTML_SANITIZATION = False
CONTENT_SECURITY_POLICY_WARNING = False
"GENERIC_CHART_AXES": True,

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Add any other context about the problem here.

+1 can confirm the same issue, on Superset 2.1.0

Is this still an issue in 3.x? I've heard things are working better now, but would like confirmation on this one.

Closing as stale... happy to reopen if people are facing this in currently supported versions.


Add e2e tutorial for fraud detection

Closes https://issues.redhat.com/browse/RHOAIENG-532
Description

Adding a dashboard tile for the "OpenShift AI tutorial - Fraud detection example" guide.
How Has This Been Tested?

Deploy all the rhoai documentation with oc apply -k manifests/overlays/apps/base/rhoai
Check that there's a new doc in the resources section

Test Impact

No testing required, new resource added, no changes in the codebase
Request review criteria:

Self checklist (all need to be checked):

[X] The developer has manually tested the changes and verified that the changes work
[X] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

/retest

Gonna approve to fix the issue that will affect other PRs

/approve


Cache welcome views

Testing #111517
See attached recording. After reload or start, empty views change nervously because contents comes in late and only after each extension has been processed. We had a similar problem with activity-bar icons and use an optimistic caching strategy which assumes that you still have the same extensions installed

/cc @sandy081 for consulting


generateSecureKey really returning list

generateSecureKey really returning list instead uint8list.

Uint8List is an extension of List afaik. So it shouldn't cause any issue. Can you elaborate a bit why you think doing toList() is necessary?

I keep getting this error, but I think it is a very specific error. I'll close this PR.


fix(typescript-webpack): checkerPlugin error in EasyWebpack

Got the below error. Fixed it with the proposed change.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Hey, thanks for this, although I've already fixed it here (where it should be): https://github.com/easy-webpack/config-typescript/commit/b74a32998fb2b0b549598d6d9d6efc49a0a4f2f6
Not sure why the CI is still erroring though.

Looks like config-typescript needs another release before the fix will be picked up in the skeleton though.

That's right @gbaldeck, the CI didn't build it properly. Sorry about that. Should be fixed now.

@niieani Just an FYI that https://github.com/easy-webpack/config-typescript/releases/tag/v5.0.1 did not fix the CheckerPlugin issue. I still get the same error if I don't include it explicitly in my webpack.config.ts.

It did fix it. It's confirmed in the CI. You need to run npm update.

You're right. I needed to do a yarn upgrade to recreated my lock file.


[Stream Analytics] Add Subscription Level APIs

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[X] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.

April

When you expect to publish swagger? Please provide date, or month to public if date is not available yet.

March

If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No, no need to refresh for updates in this PR

Contribution checklist:

[X] I commit to follow the Breaking Change Policy of "no breaking changes"
[X] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[x] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[X] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[X] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

Please resolve the breaking changes flagged by the tool. Adding new endpoints need a new api version.
https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md#api-changes-that-require-a-version-change
If you have a justification for breaking changes, please follow the breaking change review checklist in the pr description to get approval.

@j5lim, could you take another look at the updated PR please? thank you!

@roslynlu You are introducing breaking change to old preview version. Please submit for breaking change review.

@Roslyn Lu Please fix all the CI issues

@PhoenixHe-msft, I believe I have fixed everything, is there anything else I need to do for this PR to be merged?


"Error: spawn EACCES" on image upload after deploying

Hi,
After running into many issues I successfully deployed the function to Lambda. Uploading an image triggers the function. In CloudWatch logs I'm getting:
Reducing to: ./reduced
{"errorMessage":"Error processing original/my-image.jpg: Error: spawn EACCES"}
Did anyone encounter this? from I read it's not an aws permission issue but an NPM issue.
Thanks!

I have the same issue.
"errorMessage": "Error processing photos/-KsDt7AupIzmQaYLxH74.jpg: Error: spawn EACCES"
My permission allows me a full access to S3.

@stormcrow85 @wandri
I guess EACCESS means permission related error. But this project deals with S3 files as binary string, so permission isn't cause of that.
However, image reduce binaries which bundled in this project might not have a permission when packaging. So could you try to add a executable permission?
$ chmod +x bin/linux/*

Or, try this branch: https://github.com/ysugimoto/aws-lambda-image/tree/feature-binary-permission This branch works apply executable permission before spawn process.

Thanks @ysugimoto
I'm using the branch feature-binary-permission
I am now getting:
"errorMessage": "Error processing myImage.jpg: Error: EROFS: read-only file system, chmod '/var/task/bin/linux/cjpeg'"
I've read that some people were able to bypass this with writing the files to the /tmp folder, but i am getting the impression that this is not a good practice, and in 2017 it's not needed anymore on Lambda.
With that being said, I still cannot find any way to make this work
I also tried deploying the code on an EC2 instance with an identical environment to Lambda, and copying the files from there, also didn't work for me

@stormcrow85 Thank you for reporting.
I investigated, and the serverless fixes as you said: https://github.com/serverless/serverless/pull/1631
If this problem caused by zip file, probably we confirm how Claudia.js makes it.

and in 2017 it's not needed anymore on Lambda.

Wow, where could I see that information?

Thanks for investigating @ysugimoto, I'm looking into the fix you mentioned.
Regarding chmod and moving files to tmp folder (on Lambda) - see the following answer:
https://stackoverflow.com/a/29001078/1185447

Hi @ysugimoto
Finally, it's working. I reverted back to the original repo and started from scratch.

I created a new EC2 instance with environment identical to Lambda:

AMI name: amzn-ami-hvm-2016.03.3.x86_64-gp2
Linux kernel version – 4.4.51-40.60.amzn1.x86_64
Node.js – v4.3.2 and 6.10.3

Git clone to local folder and uploaded to EC2

chmod +x bin/linux/*

npm install .

zipped the folder on EC2 using bash zip, and uploaded to Lambda

Image is processed successfully after triggering image upload from S3 bucket

Just writing this as a future reference for anyone who might encounter this:
I figured that probably using a Windows machine is at fault here. The only time I was able to get it to work is by deploying, chmod and zipping on the EC2 linux machine. I suspect that like the issue referenced above the Unix permissions are not saved correctly in the zip file.
Thanks for all the assistance @ysugimoto

Sounds great!
Well, on windows, it might be better to work on virtual env (eg Vagrant, docker) to create zip archive and uploading via Claudia.js.
I'll add virtual machine setting file for windows and look into node-archiver which uses at Claudia.js.
Thank you for solving problem @stormcrow85


Feature pyroscope

Description:
This PR adds scripts to install Pyroscope as an online/dynamic profiling tool in OSM namespace.
Pyroscope is installed in Golang pull mode. It requires the Golang service to have pprof debug web endpoint setup. Therefore right now osm-controller can be profiled. Other components such as osm-bootstrap and osm-injector do not support online profiling.
Resolves https://github.com/openservicemesh/osm/issues/4694

Testing done:
Tested the script in development cluster. Pyroscope is properly installed.

Affected area:

Functional Area

New Functionality
[ ]

CI System
[ ]

CLI Tool
[ ]

Certificate Management
[ ]

Control Plane
[ ]

Demo
[ ]

Documentation
[ ]

Egress
[ ]

Ingress
[ ]

Install
[ ]

Networking
[ ]

Observability
[X]

Performance
[X]

SMI Policy
[ ]

Security
[ ]

Sidecar Injection
[ ]

Tests
[ ]

Upgrade
[ ]

Other
[ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project?

Did you notify the maintainers and provide attribution?

Yes. The script is modified from Pyroscope official example. We didn't inform the maintainer.

Is this a breaking change?

No

Has documentation corresponding to this change been updated in the osm-docs repo (if applicable)?

Documentation task is tracked by https://github.com/openservicemesh/osm-docs/issues/368

Codecov Report

Merging #4744 (d559100) into main (0ad92c9) will increase coverage by 0.05%.
The diff coverage is n/a.

:exclamation: Current head d559100 differs from pull request most recent head 40eaaf1. Consider uploading reports for the commit 40eaaf1 to get more accurate results

@@            Coverage Diff             @@
##             main    #4744      +/-   ##
==========================================
+ Coverage   69.47%   69.53%   +0.05%
==========================================
  Files         217      225       +8
  Lines       15524    15983     +459
==========================================
+ Hits        10785    11113     +328
- Misses       4689     4819     +130
- Partials       50       51       +1

Flag
Coverage Δ

unittests
69.53% <ø> (+0.05%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/certificate/providers/certmanager/helpers.go
0.00% <0.00%> (-20.41%)
:arrow_down:

...certificate/providers/vault/certificate_manager.go
58.57% <0.00%> (-14.65%)
:arrow_down:

cmd/cli/verify_connectivity.go
26.31% <0.00%> (-10.53%)
:arrow_down:

pkg/certificate/providers/tresor/ca.go
61.40% <0.00%> (-8.46%)
:arrow_down:

cmd/osm-bootstrap/osm-bootstrap.go
39.91% <0.00%> (-3.49%)
:arrow_down:

...ertificate/providers/tresor/certificate_manager.go
63.63% <0.00%> (-1.32%)
:arrow_down:

pkg/configurator/client.go
88.97% <0.00%> (-1.14%)
:arrow_down:

cmd/osm-controller/osm-controller.go
13.87% <0.00%> (-0.97%)
:arrow_down:

pkg/certificate/manager.go
81.61% <0.00%> (-0.70%)
:arrow_down:

...icate/providers/certmanager/certificate_manager.go
29.56% <0.00%> (-0.53%)
:arrow_down:

... and 25 more

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 0ad92c9...40eaaf1. Read the comment docs.

@jaellio Well I feel both approaches are ok. I prefer leaving it here. The files in osm-docs manifests/ are for OSM demo. I feel Pyroscope feature is not a pure demo, although we can create a feature demo in OSM documentation.

@nojnhuh do you mean moving the script and configuration both to the osm-docs repo? I do agree with the ease of discovering point.

@nojnhuh do you mean moving the script and configuration both to the osm-docs repo? I do agree with the ease of discovering point.

Yeah, I think keeping all the Pyroscope stuff as close together as we can is easiest to manage.

@nojnhuh That make sense. I will drop this PR and move it to osm-docs as an instructional guide.
cc @jaellio


Referenced ContentPart missing after using serialization

Dear all,
Take the 1-n example  as an example.
Steps I did to get the example working again:

Changed target framework of project to ".NET Framework 4.5.2
In Driver-classes I removed attributes "[UsedImplicitly]" and "using JetBrains.Annotations;"
In Method "UpdateFrom1" in Migration.cs I added the following ContentType for testing purposes:

ContentDefinitionManager.AlterTypeDefinition("AdressTypeTest", type => type
            .WithPart(typeof(CommonPart).Name)
            .WithPart(typeof(AddressPart).Name)
            .Creatable()
            .Listable()
            .Draftable()
            .Securable();

In the example code of "AddressPart.cs" we see the following lines:
public StateRecord State {
    get { return Record.StateRecord; }
    set { Record.StateRecord = value; }
}

In the tutorial however is the following line, supposedly to enable XML-caching:
public StateRecord State {
	get {
		var rawStateRecord = Retrieve<string>("StateRecord");
		return StateRecord.DeserializeStateRecord(rawStateRecord);
	}
	set {
		var serializedStateRecord = StateRecord.SerializeStateRecord(value);
		Store("StateRecord", serializedStateRecord);
	}
}

But this code in the tutorial causes strange things to happen when one follows these steps:

Create a new instance of AdressTypeTest (or how you named the ContentType that the AddressPart is attached to).
Assign it a state by clicking on the ComboBox "Choose a state.."
Click on "Publish now".
Go to the link "Content" of the Admin Menu
Click on the "edit"-link of the ContentItem that has just been created.
Remove the selection for state - so that "Choose a state.." is visible again.
Click on "Publish now".
Immediately afterwards the whole "AddressPart" seems to be gone! But it should not, of course!

Greetings
egdd

Kind of a documentation issue, need to find what is wrong with it.


[BUG] Missing index for "log" collection

Describe the bug
Log collection in database takes too much disk space after some time in production. By default there is only index for _id. Please add automatic index creation for field UtcTimeStamp, to make future queries efficient. This index can be defined as TTL, with expiration time defined, or the whole collection could be defined as capped collection with size limit for example 1GB.
Expected behavior
Fast queries on Log collection based on field UtcTimeStamp, with automatic clean up of collection of older entries or capped by disk space.

/cib


JSQMessenger Add Geo Location in each messagetype

Is this possible in JSQMessenger to add geo location in each message. I havent seen any property yet.
There is a JSQLocationMediaItem but its adding a new mediaItem with map image.

Hey @saad-rehman - this isn't implemented, but you can subclass JSQMessage to add this


Build(deps-dev): Bump rimraf from 4.1.1 to 4.1.2 (#4562)

Pull request opened by the merge tool on behalf of #4562

Merged in 58781049e0f883aa5fbfd880e62acce4b0db7b9c


Fix SA1121 SyntaxToken.Text usage should have been SyntaxToken.ValueText

I found this :bug: in code coverage reports, not in a user feedback (thankfully; no one should have code like this).

:+1: There is always someone doing it. :laughing:


Typo on website

Link > Style > Typography:
Link text should be ~set in~ set in sentence case with the first letter of each word capitalized. Links should not exceed three words.

:+1: Good to know. Just curious, what's the thought process behind not using sentence case v10 on?

@tsaitsaitsai We haven't changed anything around when to use sentence case, I think the wording was removed here because someone found it confusing in regard to links. Links will follow whatever capitalization rules depending on where they are. All the capitalization rules can be found here https://next.carbondesignsystem.com/guidelines/content/guidance#capitalization