Aqara Motion Sensor

Brought one to test the occupancy sensor alongside my Hue motion sensors after talking to @frenck. If they outperform the Hue motion sensor I will consider upgrading to them and selling my Hue sensors (11 indoor, 7 outside).

Ali Express
Amazon

Well it arrived. Much smaller than I expected. Now I plan to run some side-by-side tests with the Hue sensor.
First thoughts are is that is pretty damn quick at detecting motion, as well as detecting repeated motion. It also seems more accurate in detecting idle presence (room occupied but sitting still). I’ll continue with some tests and share my thoughts.

I wanted to give these two sensors a fair review. This isn't a particular scientific review but a review to compare the two devices side-by-side.
Sensors
These devices contain a number of sensors that are exposed and available in different places. Both devices include temperature and light level (LUX) sensors. Previously when I had the Hue sensors integrated via the Hue bridge the humidity was also exposed.

Sensor
deCONZ Hue
deCONZ Aqara
HA Hue
HA Aqara

Motion
Yes
Yes
Yes
Yes

Temperature
Yes
Yes
Yes
No

Humidity
No
No
No
No

LUX
Yes
Yes
Yes
Yes

Battery
Yes
Yes
Yes
Yes

Motion refresh rate
To test the refresh rate I waved my arm continuously to see how often the device refreshed and if the state changed. For no motion, I placed the sensor in a cupboard. What was interesting is that the Aqara refreshes regularly whereas the Hue sensor doesn't update until no motion is detected. Furthermore, the Hue sensor becomes idle within 10 seconds but the Aqara takes 100 seconds to become idle after no motion is detected.

Device
Continued Motion
No motion

Aqara
5 seconds
100 seconds

Hue
Hue remains active
10 seconds

Temperature variance

Device
Temperature

Aqara
28°C

Hue
22°C

Aqara Temperature Sensor
23°C

Test thermometer
24.1°C

LUX variance
Both sensors reported close results when placed in the room but when placed in a closed cupboard with my Petzl Reactik + head torch (with three modes 110, 1350, and 2700 lux) the senors reported very different results. The torch was placed at close range within a cupboard. The Hue sensor appeared to be more accurate where at the Aqara seemed to max out at 851. The results in the room appear to be

Device
Dark cupboard
Torch (high) in cupboard
Torch (low) in cupboard
Room

Aqara
3 lux
851 lux
851 lux
192 lux

Hue
1 lux
14447 lux
6132 lux
137 lux

Note: I use a Conbee II zigbee gateway and deCONZ running in Docker.

Here is a basic history comparison between the Hue and Aqara in a frequently active room.

I've continued to use Hue motion sensors as my primary room motion sensor. The Aqara would be great for projects in the future.


move nexus deployment to statefulset

What this PR does / why we need it:
This PR moves the deployment and PersistentVolumeClaim to statefulset and volumeClaimTemplates
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
With the addition of nexus-backup, deployment is useless now. It will not manage to crate 2 disks in the same zone and because of this it will never create the pod.
Special notes for your reviewer:

Please sign the CLA and increase the chart version to at least 2.0.0

Hi. I signed the CLA, but I don't know how to verify it. It will appear automatically here?

CLA is showing up

@jeff-knurek Can you take a look at this? Have you had any issues with the 2 pvc configuration?

hmm, no I haven't had any problem with disks not being created, but I've only tested it in GKE, so maybe there's some more info needed to reproduce this issue @cristifalcas

I could put the links to the various issues regarding this. In aws, at least, is happening all the time. Disks are created in multiple azs

ok, so it's a bug in AWS, and the workaround is to switch from deployment to statefulset?

I was speaking about this: https://github.com/kubernetes/kubernetes/issues/59326
And here is where they say that it works only for statefulsets:https://github.com/kubernetes/kubernetes/issues/59326#issuecomment-362974193


maintaining.md: new find_outdated_appcasts label

Pinging @caskroom/maintainers to underline the point: should never be applied manually.
Currently working on the script.

Understood. :+1:

For a bit more context, said label should only be applied by that script because I’ll later make another one that’ll loop through all the issues with said label.

Made some changes to the label. Still should never be applied manually, but it will also be applied to PRs.

:+1: Where are the scripts hosted? Couldn't find them in your tiny-scripts repo. Want to go ahead and open a PR to host them here? You can continue to refine them, and we can offer feedback :smile:

Where are the scripts hosted?

Nowhere yet. Have been building/refining all day.

Want to go ahead and open a PR to host them here in developer/bin?

Yes. These ones definitely belong in developer/bin, not tiny-scripts. I’m still finishing everything up (small tweaks here and there) and building/thinking about latter parts of the process — ideally grab all PRs with the outdated appcasts tag, and if they passed the build, auto-merge them; but unfortunately so far haven’t found a way to check via CLI if a Travis build has passed.
Finishing that up is basically the reason I haven’t submitted them yet (making so many changes by the minute and cutting and moving so much between them, they’re not even under version control, yet).
I’ll probably finish them tomorrow (and hopefully will find a way to do the Travis check, for the auto-merge script), and then I’d like to do a full run (only did partial ones today) to make sure everything is OK before submitting.
They’re being surprisingly straightforward and small to build, so review should be simple.

unfortunately so far haven’t found a way to check via CLI if a Travis build has passed

hub ci-status {{commit}} should do the trick.
When testing the auto-merge, just to be safe, you might want to use your own fork as the source repo until you're confident it works as you expect.

When testing the auto-merge, just to be safe, you might want to use your own fork as the source repo until you're confident it works as you expect.

Yes, I usually do create temporary repos to test features, specially the most annoying ones (like opening issues) until I get them right.

Could also add a section to contributing, in updating a cask:
If you want to jump right in, outdated Casks are listed as issues with the "outdated appcast" label. Use cask-repair to easily submit a PR to close the issue.

Not really needed. I also have a script that does one better than that (which is why the label is actually useful).

Merging. Will submit the scripts shortly.

https://github.com/caskroom/homebrew-cask/pull/18237.


Feedback Mechanism for Users

https://marker.io/blog/website-feedback-tools

I'm wondering if we could do something cool here like require a balance of 35k bank to submit feedback.


TypeError: unsupported operand type(s) for -: 'int' and 'simsimd.DistancesTensor'

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code
_embedding = VertexAIEmbeddings(project="PROJECT_ID",
                                             credentials=gcp_auth.credentials,
                                             model_name="textembedding-gecko@003",
                                             location="PROJECT_LOCATION")

 _db = PGVector(connection_string="CONN",
                            collection_name="COLLECTION_NAME",
                            embedding_function=_embedding,
                            use_jsonb=True)

_db.search(query="test", search_type="mmr")

Error Message and Stack Trace (if applicable)
Traceback (most recent call last):
  File "/Users/amit/telly/telly-backend/backend/agent/healthcheck/components/hc_vector_db.py", line 29, in check_health
    db.search(query="test", search_type=self.settings.vector_db.retriever.type)
  File "/Users/amit/telly/telly-backend/backend/venv/lib/python3.12/site-packages/langchain_core/vectorstores.py", line 160, in search
    return self.max_marginal_relevance_search(query, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/amit/telly/telly-backend/backend/venv/lib/python3.12/site-packages/langchain_community/vectorstores/pgvector.py", line 1236, in max_marginal_relevance_search
    return self.max_marginal_relevance_search_by_vector(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/amit/telly/telly-backend/backend/venv/lib/python3.12/site-packages/langchain_community/vectorstores/pgvector.py", line 1314, in max_marginal_relevance_search_by_vector
    docs_and_scores = self.max_marginal_relevance_search_with_score_by_vector(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/amit/telly/telly-backend/backend/venv/lib/python3.12/site-packages/langchain_community/vectorstores/pgvector.py", line 1196, in max_marginal_relevance_search_with_score_by_vector
    mmr_selected = maximal_marginal_relevance(
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/amit/telly/telly-backend/backend/venv/lib/python3.12/site-packages/langchain_community/vectorstores/utils.py", line 34, in maximal_marginal_relevance
    similarity_to_query = cosine_similarity(query_embedding, embedding_list)[0]
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/amit/telly/telly-backend/backend/venv/lib/python3.12/site-packages/langchain_community/utils/math.py", line 29, in cosine_similarity
    Z = 1 - simd.cdist(X, Y, metric="cosine")
        ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TypeError: unsupported operand type(s) for -: 'int' and 'simsimd.DistancesTensor'
           INFO     Cannot execute Healthcheck: hc-vector-db  hc_vector_db.py:33

Description
Library Versions Used:

langchain~=0.1.14
langchain-google-vertexai~=0.1.2
simsimd~=4.2.2

System Info
NA

Let me see

i also enounter the similar problem with  LaserEmbeddings embedding:(

installing simsimd == 3.7.7 works for me from andy-tmpt-me's answer.
https://github.com/langchain-ai/langchain/issues/18022


Enhanced instanceof

Proposal for an enhanced instanceof which will test against a list of classes that is still backwards compatible.
The enhanced syntax would be as follows:
if a instanceof [<list-of-classes>]
   # ...

which would compile to
if (a instanceof <first-class-in-list> or a instanceof <second-class-in-list> or ... a instanceof <last-class-in-list>) {
  // ...
}

+1, structured exception handling seems like one of those things everyone's still rolling for themselves.

+0.5, looks potentially handy

I'd give this issue +1 if instanceof would be idiomatic way to check instancing. Consider following examples:
1 instanceof Number  # false
true instanceof Object  # false
true instanceof Boolean  # false

new Boolean(true) instanceof Object  # true

At this point, :-1: from me.

Duplicate of #794. This proposal has the unacceptable inconsistency that a instanceof [b, c] would not be equivalent to d = [b, c]; a instanceof d. It's worth noting that satyr/coco supports this.
@paulmillr:
$ node
> Object(1) instanceof Number
true
> Object(true) instanceof Object
true
> Object(true) instanceof Boolean
true
>

This proposal has the unacceptable inconsistency that a instanceof [b, c] would not be equivalent to d = [b, c]; a instanceof d

It's safer to treat [] variant of {instance,}of specially:
$ coffee -e 'undefined in [console.log 0; console.log 1]'
0

$ coffee -e 'undefined in {} = [console.log 0; console.log 1]'
0
1

They're fundamentally different because of short circuit.

Actually this was meant as an extension to the compiler that when detecting
foo instanceof [bar, jar, car, war]

it would insert boilerplate code that would then replace the above with
foo instanceof bar or foo instanceof jar or foo instanceof car or foo instanceof war
was this so difficult to understand from what was depicted in the description?

of course [] could also be replaced by just opening and closing standard brackets...

but then again, python supports multiple inheritance whereas javascript does not...


Traitlets config

Replacement for #173: I've rebased on the latest master after merging the drives names PR. So it should be exactly the same (with addition of mount_dir).
Once #174 gets merged, I'll rebase and see if the tests succeed (but feel free to have a look if you have time).
Closes #148
Closes #109

@mateusz-garlacz yep, feel free to re-open the other and I'll close this

But we still need to rebase on top of the tests, which is not merged yet.


adding new gestures

hi !
I am new to this part of coding and am unable to understand how to add a new gesture to the given setup .
could you walk me through it . ??
thanks

Hey,
For doing that you will require to capture new sample images (option available in the script) and then retrain the CNN network along with it.
I might be able to reply back with detailed steps by end of this week only.

Ohh..... I figured it out..... But forgot to close the issue..... Sorry about that......
What I don't get is how does the program understand which gesture a sample image represents......does it take it from the name or smtg??
Anyway..... Thnxs for the program...... It works great

Hey,
Sorry to bother you again, but i am a complete beginner in this field.
I was able to train new finger gestures, but the problem statement of my
project changed a little, so i was wondering whether the same program can
be retrained to work properly for complete arm gestures like recognizing
gestures like raised right arm, both arm raised, etc.
Also, i was wondering, when i added gestures, I just took images and named
them after the gesture, and trained it, but i was wondering while training
how does the program know which gesture a picture is a sample of.
Thank you again , and sorry for bothering you,
Aadarsh Pratik
ᐧ
On Thu, Feb 15, 2018 at 12:20 PM, Abhishek Singh<EMAIL_ADDRESS>wrote:

Hey,
For doing that you will require to capture new sample images (option
available in the script) and then retrain the CNN network along with it.
I might be able to reply back with detailed steps by end of this week only.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/asingh33/CNNGestureRecognizer/issues/14#issuecomment-365840011,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ab-1I0Ix3AbHc1wVjqUuXZH6Gn-O55lEks5tU9OxgaJpZM4SBD85
.


How to run rust code using wasmi?

What is command to run code in rust? (wasmi is installed as per https://github.com/paritytech/wasmi)
Tried cargo build --target=wasm32-unknown-unknown
How can I connect it to web server?
Tried with cargo web start --target=wasm32-unknown-unknown  but code is not executing.
When I run command  cargo run --example=tictactoe
Getting the message
Usage: target/debug/examples/tictactoe <x player module> <y player module>
But Im not getting how to assign player modules
All helps are appreciated. Thanks in advance

@AchalaSB Why are you using wasmi?
Are you just trying to compile Rust code to wasm and then run it?
If so, then you don't need wasmi at all, instead you should use one of two options (not both!):

Follow the directions for stdweb.

Follow the directions for wasm-pack.

Thanks for filing an issue.
If your goal is to run wasm on the Web, then wasmi shouldn't come into play. wasmi is for if you want to embed running wasm in your application (say as scripting for a game).
@Pauan's links should provide more guidance. Additionally, you might benefit from going through the game of life tutorial: https://rustwasm.github.io/book/game-of-life/introduction.html

@Pauan  Yes. Im trying to run rust code to wasm. As you said tried with stdweb. But code is not running in server ( refer #141)


Installing a package doesn't add it it to path

Brief description of your issue
Installing a package doesn't add it it to path
Steps to reproduce

Install Vim using
winget install Vim
Try to run it using
Vim test.txt

Expected behavior
Vim should open the file if it exist or create a new file.
Actual behavior
Vim : The term 'Vim' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included,
verify that the path is correct and try again.
At line:1 char:1
+ Vim .\test.txt
+ ~~~
    + CategoryInfo          : ObjectNotFound: (Vim:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Environment
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19041.450
Package: Microsoft.DesktopAppInstaller v1.10.42241.0

Is this essentially a duplicate of #222 ?

This isn't an exact duplicate, because opening a new shell doesn't change the behavior. the Application is still not in the PATH.

This isn't an exact duplicate, because opening a new shell doesn't change the behavior. the Application is still not in the PATH.

Makes sense-- it does not appear to be a problem with winget, but with the vim package; I guess the question then becomes how should winget handle packages that don't add themselves to PATH? Is this exclusive to the vim package, or have other packages shown this behavior too?

Rather than populate your PATH like Chocolatey, winget should add shims like Scoop(UWP also has this feature)
https://github.com/microsoft/winget-cli/issues/361

@matifali this path problem is not because of winget-cli.
The actual installer of vim does not add vim directory to the path. So this is not an issue of winget-cli.

Yes I understand But wiget-cli should not accept such packages in repo if they don't add themselves to path.

Is there any due diligence performed on the items in the winget repos?  Does Microsoft do any validation of applications??

Is there any due diligence performed on the items in the winget repos? Does Microsoft do any validation of applications??

Most probably no.

Rather than populate your PATH like Chocolatey, winget should add shims like Scoop(UWP also has this feature)

@Witchilich Sorry to jump in. I just wanted to note that Chocolatey brought about the idea of shims not to clutter your PATH - it existed long before Scoop was created as a concept called batch redirects. Later we moved to shim exes. Luke thought shimming was great and added it to Scoop. Just want to make sure the credit is in the proper place on shims.
References:

November 2013 - Issue for Shim Exes for Chocolatey w/commits in November 2013 - https://github.com/chocolatey-archive/chocolatey/issues/372
January 2014 - Added to Scoop - https://github.com/lukesampson/scoop/commit/5c52166fcd813aaee0865e50f516b09d696bf9c7#diff-6102f557c61df6fb4e37e4e68d8899348e48b633871262f5fd1c27ed42caf4dd

I think your confusion might be in that Chocolatey defers to an installer as well, which might put things on PATH. Scoop doesn't use the installer at all, it just unpacks, so the shims are much more necessary.  How can you figure out where vim actually installs. I’ve tried winget list vim and can’t figure it out. Do I look at the source. Same issue with winget install git by the way.

Is this still pending? Does anybody know a workaround?

Being able to easily install vim with winget should be a core use case of winget.

I just tried winget for the first time on a brand new windows 11 system from dell and encountered this.

entered winget install whois ,
then restarted terminal / powershell,
entered whois and received whois : The term 'whois' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

This is completely unacceptable and an absolute non-starter for a package manager. this is the application level equivalent of installing an operating system without adding it to the bootloader. fixing this should be priority 1. thank you

workaround:
After installing vim.vim with winget, the quick way to add it to path:
right click start button, select run
run the following command: systempropertiesadvanced
go to Environment variables, select Path
[Edit...]
[New]
C:\Program Files (x86)\Vim\vim82\
Since the vim version number is used in the directory name, you might have to find new the location of newer vim versions by searching for it in the start menu, right click, 'open file location' and adjust the path accordingly
restart the command prompt/windows terminal for it to take effect

While that would surely work and the flow could be reduced to a PowerShell snippet I'm not sure about the manageability of adding hundreds of packages to the path (my workstation has a bit more than 110 packages, although not all should be in the global path).
I should note that chocolatey, which I used previously, creates a «shim» exe in a global directory that is added once to the path.
That approach seemed to work well for me.

The shims have the advantage of not needing to update every program's environment after installing a package. This would help us implement CI/CD pipelines with Winget.

How was this not the first item on the to do list? It's a terminal command, it should work from the terminal. I'm glad I tested this out on a VM first because I still don't know where it put git. Is there any way to tell it to add to the path? I'd gladly accept a bad wrong way of doing it over this. The frustration is there because people like what you're doing, what would it take for us to get this actually working so people who use the terminal can use it?

Hello @denelon , trying to give winget a second chance. I thought well maybe it's not really for terminal programs. I hit a similar (less impactful) issue again today where I followed the guide at https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell?view=powershell-7.3 where I ran winget install --id Microsoft.Powershell --source winget and it installed... but initially I couldn't find it at all. I was able to find it by searching for powershell, as "powershell 7".
I'm not used to new versions installing as separate programs. Typically when I install a program it actually replaces the older version unless otherwise specified. If I use winget to provision machines, people are going to run the old old version of powershell that is still there because the old version comes up first in the search. When I call the powershell command, it true to this issue it still calls the old powershell. It feels like the team isn't dogfooding winget to provision their machines, because this tool is missing very simple and very critical comforts.
Normally I would make a new issue for something like this, but I'm afraid you would prioritize it over fixing the paths issue, and if that's the case I don't want this fixed. I would pay a fair bit of money to stop all other issues until this issue is fixed since it severely limits the default windows experience especially compared to the competition.

It's not a issue with WinGet, that's how PowerShell is handled even if you manually use the installer. They are installed as separate programs because the version from GitHub can't replace the system version without being handled in special ways. Having it as a separate program allows for faster upgrades and other things that would normally have to be locked behind the normal update cadence

Alright, thanks @Masamune3210 . I think that's a really dumb decision by msft that it's not possible to update powershell but also clearly not winget's fault here.
As an aside, that I guess I'll have to bring up in the powershell repo? I get that Microsoft might need a fixed version of powershell behind the scenes but I feel like bare minimum I should be able to update powershell for user space, where when I call powershell it uses the newest powershell, and the shortcut for the old old powershell no longer shows up... It's just bad UX. It gives the impression that it didn't work, since you open powershell and it's still old. Call the powershell command, still old.

@voronoipotato thanks for the detailed feedback here.
We've been discussing several challenges associated with required environment variables like "path". We implemented support for path in the portable install flow, but we're still dependent on the package installers to handle this correctly today for other installer types.  Part of the "upgrade" challenge is also associated with what type of an installer is actually being used.
MSIX packages upgrade natively (although there are still some bumpy experiences like upgrading winget by running winget upgrade "App Installer" -s msstore). For MSI "upgrades" we use the Product Code or the Upgrade Code to upgrade the "same" package. Traditional ".exe" based installers are essentially still much more challenging as they might do anything.
As there aren't graceful ways to deal with switching installer technology, we prompt the user when the installer type changes, and inform them that they need to uninstall the version on their system before installing the newer version. We've added keys to the manifest for "uninstallPrevious" when we know the earlier version should be removed, but in some cases, a side-by-side install is "by design".
We're adding extra metadata to manifest so we know what the "default" path and "default" program are. Something like that may lead us to a point where we could decorate a manifest such that we know the installer doesn't add the path, so we could inform the user that it's something they could/should do. Changing environment variables will still require a shell restart or a reload environment variables to actually function. That's likely something we would still want a user to actively do so we don't inadvertently break something else running on the system "at the same time".

@denelon I'm going to talk a little bit about git, as a way of talking about strategy with installers. Git appears to have silent/unattended installation flags. https://github.com/git-for-windows/git/wiki/Silent-or-Unattended-Installation Does winget currently support the ability to use those? Or we could use the portable similar to how scoop does https://github.com/ScoopInstaller/Main/blob/master/bucket/git.json . It feels like critical packages have been broken for months or years, and that's really very bad for winget. If there's an incorrect way to do something, people will do it. If software that people rely on is provided in non-working condition, it will erode and eventually destroy winget. Nothing is more important than trust with a package manager.
I still have not "bought-in" to trusting winget, but the value it could provide if I can use it to quickly script installations on a developer's machine or server is incredibly obvious. If anyone doubts it, tell them to try Fedora or any other major Linux distro for a day where any software from any provider is available with ease. I can add external repositories from microsoft, dell, or anyone I want, as well as using a well curated list of packages that are certain to work well. It's something that I miss a lot every time I go to a windows server or my work computer.

Yes, today, WinGet uses the "known" installer types like inno, nullsoft, wix etc. as hints to determine things like installer switches for silent or "silent with progress" (our default mode). We also support switches for those modes when they are unique (this is very common with traditional .exe-based installers). They may also help with knowing how to do a "user" vs. a "machine wide" install.
For Git, winget install git.git --silent or winget install git.git -h should perform a silent installation without any output.
One of our critical goals early on was to meet developers (packages) where they are, and not to require them to be rewritten or to have to completely rewrite their installers. That does lead to challenges when the installer doesn't have parity in "silent" with what is supported via "interactive".
I see this as a bit of a "chicken and egg" challenge. We need a package manager as a bit of a forcing function to establish best practices. As you are stating, if the packages aren't ever "fixed", or the package manager can't reason about them, then it's a bad experience. We have taken the approach to assert rational "default" behaviors, and then extend with settings and arguments so the desired outcomes can be achieved. Today we have "--override" which allows overriding arguments WinGet defaults to with the manifest/installer type so users can specify the arguments they want. We also have an ask for an "augment" type of behavior so we can preserve the default switches and simply "add" to them.

So can we provide those flags in the installer.yaml, or is that not implemented yet?

If there are arguments that set the path correctly, then yes, they could be added to the manifest. It may still require a restart of the shell or the environment variables to make it available. You can test locally with "-m ". In some cases, those arguments haven't worked when the install location was modified by the user.

For my Windows 10, Neovim was installed on C:/Program Files/Neovim and the launch executable is C:/Program Files/Neovim/bin/nvim.exe. I had to restart the command prompt to be able to invoke nvim to start Neovim.

I just tried installing a package with winget. It was relatively easy to use winget search to find the package and winget install package similarly "just worked".
Then I got very sad when apparently it didn't "just work" and my package was seemingly not installed. It's not on the path, and since I have no idea where it got installed, it may as well just not have been installed at all.
This makes winget pretty much useless. Please prioritize this issue ASAP. Until this is fixed, I don't see any value in winget.

@Victor-N-Suadicani which package are you referring to? Can you share the WinGet logs?

Just trying to install vim and git with winget. How is this so incredibly more difficult than on Linux? How do you figure out what path to add to Windows? And even once found, the process to add a path on Windows?!?! Ridiculous. Agreed, winget is useless.

@Victor-N-Suadicani which package are you referring to? Can you share the WinGet logs?

It was GnuWin32.Make in my case, but clearly it happens to many other packages as well.

I know right. :-(
Sent via Superhuman iOS ( @.*** )
On Mon, Nov 28 2022 at 07:50, Python, vim & git! Mike Levin gets you onto Linux < @.*** > wrote:

Just trying to install vim and git with winget. How is this so incredibly
more difficult than on Linux? How do you figure out what path to add to
Windows? And even once found, the process to add a path on Windows?!?!
Ridiculous. Agreed, winget is useless.
—
Reply to this email directly, view it on GitHub (
https://github.com/microsoft/winget-cli/issues/549#issuecomment-1329331289
) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AANTCR3QANXQRCEJHZSSIO3WKTIE5ANCNFSM4QMBC3FQ
).
You are receiving this because you commented. Message ID: <microsoft/winget-cli/issues/549/1329331289
@ github. com>

It's up to the installer to add the package to the path (unless it's a portable package in the community repository).

Is there a way to force PowerShell or whatever happens to be the terminal that is being used to grab a fresh environment block or at least a fresh copy of the path var? I'm assuming a lot of this comes from the fact that it never gets updated except for when its first launched

I've seen a couple of examples at Stack Overflow like:
https://stackoverflow.com/questions/14381650/how-to-update-windows-powershell-session-environment-variables-from-registry

That would probably be my next guess as the best way to handle this, since most people seem to just be confused why their portable program doesn't just magically immediately work after installation, maybe have it as the last step if winget knows that a path registration is needed

It's up to the installer to add the package to the path (unless it's a portable package in the community repository).

Why is winget different in this respect to practically all other package managers? Every user is going to expect winget to add the package executable to the path. Not doing that is tantamount to a bug, especially from the perspective of a user.

I assume you are comparing the Windows Package Manager against Linux package managers. There are some very subtle differences between Linux and Windows. The Windows registry and the various "public" and "private" APIs add a bunch of complexity (read constraints). There is a long history of building an "installer" for Windows whether it's a custom .exe-based installer, or MSI, and more recently MSIX. These are of various different quality. They also generate several different "classes" of behavior that we need to be able to reason about.
Given an arbitrary installer, there could be any number of behaviors it supports (or not). Some installers don't add the executable location to the path, and WinGet doesn't "know" this information beforehand. We also don't want to go down a path where we're writing branching logic for each version of any available package. That has led us to building a more robust manifest to deal with many of these variations.
We've been discussing the notion of refreshing the path (or any other environment variables) after install or upgrade, but we don't necessarily know which shell we're being executed in to know which variables to refresh. There are differences between cmd.exe and PowerShell so there is no "one size fits all" solution there. There are other shells that handle things differently so we wouldn't know what to do for them either. Even if we were to add a prompt to "refresh the path", it might not apply in all cases.
Best practices include building a better installer (which isn't viable in the short term for many organizations) and testing the experiences with WinGet. Different packages (publishers) make different assumptions about their users, so the advent of Windows having a package manager is still "new".

@denelon Upthread, there are comparisons against Scoop and Chocolatey, both of which are Windows package managers. They both solve the "add-to-path" problem, albeit in different ways. So there are two existing solutions in the Windows ecosystem.

Scoop uses Junctions, and even chocolatey runs into the very same issue that winget is running into. Hacky solutions exist, but the hope is and should be to avoid them unless absolutely necessary

@voronoipotato I'm not familiar with neovim. If you download and "run" the installer, does it add itself to the path? I've seen a couple of cases where the "interactive" installer has an option to add the directory to the path, but when run "silently" it doesn't. I'm not sure if that's the case here or not. If it's just a switch that needs to be passed, the manifest can be updated to include that switch for "silent" and "silent with progress" variations of install.
I just ran winget install neovim in Windows Terminal (PowerShell) in user mode. I agreed to the UAC prompt. After it succeeded I closed and reopened Windows Terminal, and it appears to have worked.

@Masamune3210 That's technically not quite the same issue, since the screenshot you show is for installing Chocolatey itself. Once you've installed it, it provides a function (aliased as refreshenv) to reload your env vars, and the installation text output prompts the user to run it after something new has been installed.
FWIW, from a user perspective, I have no problem with junctions. It's a bit annoying that they require admin permissions to create (IIRC), but otherwise I've been using them without issue since...probably 2015ish, I think.

@Victor-N-Suadicani
Why is winget different in this respect to practically all other package managers? Every user is going to expect winget to add the package executable to the path. Not doing that is tantamount to a bug, especially from the perspective of a user.

I think the cause of confusion here is the fact that winget supports multiple installer types. When you have a non-portable app (e.g. msi, inno), it is the installer's responsibility to add what's necessary to PATH. But when you have a portable app (e.g. portable, zip) then it will be the manifest's responsibility to know which applications to make available.
Portable app support of winget is relatively new (see #182) and according to the following comment, it now supports adding the new app to PATH (technically, it uses a shim like Scoop instead of touching PATH with every installation, but the result is the same):

@denelon (in original thread)
...Windows Package Manager 1.3 release candidate use symbolic links for portable applications to avoid cluttering a user's path environment variable...

I believe shims are indeed the way to go as using them doesn't require the PATH to be updated with every app and it also makes the new app immediately available without restarting the shell. The use of symbolic links on the other hand sounds a bit odd considering they require elevated access to create, which is why Scoop uses junctions instead (here's a related complaint: #2802). Also, I can't find anything in the schema regarding defining what gets a shim when you have multiple executables you want in PATH, but I'm going off-topic.

The tldr; is making applications available in PATH (with or without shims) is winget's responsibility only for the portable apps. If a non-portable app (an app with an installer) needs to be called from the console, then its installer needs to update PATH accordingly.
I appreciate that this would sound more complicated than necessary to folks coming from Linux. Unfortunately, Windows app ecosystem has been all about GUIs and installers where you had to keep clicking "next" until something installed, mostly due to the lack of good CLI apps and package managers. So, it's now up to the app creators and the community to add proper support for winget. App creators can either fix their installers to add their CLI apps to PATH, or better yet, publish their apps as portable binaries (single exe or zipped) so that winget could automatically make the app available after installation.

I think the cause of confusion here is the fact that winget supports multiple installer types. When you have a non-portable app (e.g. msi, inno), it is the installer's responsibility to add what's necessary to PATH.

I'm honestly surprised winget bothers supporting non-portable apps. Why is that? I would not expect winget to support msi installers, yet it does. This is surprising. If I wanted to install something with an msi installer, I would expect that I would have to run it manually. I wouldn't want winget to run an installer like that for me.

On the contrary! I think it's quite nice that multiple installer types are supported because that way I can actually use winget to install nearly everything and even provide invocation flags for the installers to fully automate them. See for example here what I mean.

I feel that the main purpose of a package manager is to provide portable packages, not to automate or configure installers. Perhaps this functionality should have been kept behind a flag or something to avoid the confusion that occurs when users install something that then isn't actually available in the command line once installation is complete.

@Okeanos  It would be a good idea if it worked that way out of the box. It's the only package manager I've ever seen where you must provide bespoke override flags for individual packages to install as expected. The installation of a package should work without --override or it should be removed.

Any package manager I can currently think of (homebrew, apt, yum, dnf, …) allows installing complex, non-portable software. Even Scoop and Chocolatey allow that.
The overrides and additional flags I use for e.g. Git and Firefox in my example I use by choice because I wanted to maximise automation for my use case. If I wanted to do non-default things with other package managers I would have to similarly provide instructions.
So yes, I add the completely optional flags so it installs "as expected". That is expected by me. However, my expectations are likely very different from other people's expectations.
Take the Git example – there's a huge number of flags and settings users are asked to modify and choosing the "right" one for everybody is effectively impossible. winget will defer to the vendor defaults during installation if nothing else is specified and "just work". If you want different defaults that'd be on the original installer's maintainers, not winget.

What happened

**yigitemres ** commented Aug 25, 2020 •

What happened to @yigitemres's idea? This is where everyone is correct but too far into the infrastructural weeds.
Some simple interface emitting to the effect of  "winget could not confirm an installation or path location and it's possible the installer cannot either, here are some options and info, ie run THIS COMMAND and restart your terminal"
I heard @denelon  talk about how a design goal was to make it easy and inviting for package maintainers - how about the same courtesy for users of the tool? and by users, I mean at the API level. I think we are okay with some flag argument configuration, but this seems like an easy win.
I think it's hilarious there's all this comments about "MS is different than linux", lol then why make the tool at all? it's clearly a clone of Apt/etc (which is a good thing!).

Hey all, I've been talking with the team about adding some additional information after installing a portable package. The behavior depends on a few different factors. We're looking at better messaging as a hint to let the user know if they need to restart their shell/terminal or not.
In most cases, the first portable install will require the shell/terminal to be restarted.
For portable packages installed in user mode (and developer mode disabled) the shell/terminal restart will most likely be required.
For subsequent portable packages installed in admin mode the shell/terminal restart will most likely not be required.
For subsequent portable packages installed with developer mode enabled the shell/terminal restart will most likely not be required.
In this example (Vim), and with many "installers"; restarting the shell/terminal will be necessary.
In many cases with upgrade (assuming it's an upgrade to an existing package and not a side-by-side installation); restarting the shell/terminal will not be necessary.
We don't have a good reliable mechanism for dealing with a refresh of the Path environment variable as we could be called by any number of shells that all deal with environment variables a bit differently, and we aren't given the context necessary to figure out exactly what needs to be done in all cases.
We do have additional affordances possible with PowerShell and the WinGet cmdlets that may make it better, but that's not the case with cmd.exe and many others.

Do you have developer mode enabled on your machine?
Did you install via administrator or user (Terminal, PowerShell, CMD.exe).
If it appears in your user environment path, it most likely means you didn't have developer mode enabled or use an administrator shell.
I was going to test, but I get two results. Which did you install?
winget search ripgrep
Name         Id                      Version Source
----------------------------------------------------
RipGrep MSVC BurntSushi.ripgrep.MSVC 13.0.0  winget
RipGrep GNU  BurntSushi.ripgrep.GNU  13.0.0  winget

@denelon I didn't have dev mode enabled, but doing so didn't change it. I installed it as a user in a non-admin windows terminal instance using powershell.
winget install BurntSushi.ripgrep.MSVC
The first time I tried this it added the full path to %PATH%:
C:\Users\$NAME\AppData\Local\Microsoft\WinGet\Packages\BurntSushi.ripgrep.MSVC_Microsoft.Winget.Source_8wekyb3d8bbwe\ripgrep-13.0.0-x86_64-pc-windows-msvc\rg.exe
This time it added a symlink here:
C:\Users\$NAME\AppData\Local\Microsoft\WinGet\Links
But when I restart the shell it still isn't at the end of the path, either in wt or cmd.
Ah. I wonder if this is tripping on needing a logout/in for user environment changes? That's annoying if so since system path just works..

The critical timing for the symbolic link creation is when you install the package. Once it's installed, it should either be in the path with the symbolic links, or as a path entry in the environment variable. Unfortunately, a new terminal Window isn't sufficient to get the environment. The entire Windows Terminal needs to be restarted if you're using Windows Terminal.

@billwert interesting that my winget (version v1.5.441-preview) doesn't do either of those things lol. it added C:\Users\username\AppData\Local\Microsoft\WinGet\Packages\BurntSushi.ripgrep.MSVC_Microsoft.Winget.Source_8wekyb3d8bbwe\ to my PATH, which obviously isn't the correct path since, the executable is one level deeper in ripgrep-13.0.0-x86_64-pc-windows-msvc.
I also wonder when those symlinks are created. it did for yt-dlp, but I installed that with an older version of winget, so maybe that's why?

@zeratax That is related to https://github.com/microsoft/winget-cli/issues/2909 and the fix for it was merged in https://github.com/microsoft/winget-cli/pull/3002. The fix will likely appear in the next release for WinGet.

I think you need to see the product by

winget search vim

Then you choose the product that you like to install, this applies to search any other application

I would really like some movement on this. This issue defeats the point; if I cannot immediately use a command after installing with winget, then I'm not even going to waste the time. It's easier for me to just click through an msi installer.

...You cant use a command after installing it through a msi either. The issue isn't just with winget not adding to the path, the issue also lies with Terminal, Powershell, and the legacy command prompt all also not adhering to any new path changes due to only picking up environment blocks at launch and having no automatic way to refresh it if changed.

This has been a challenge for decades. If you are in a Windows process (eg in Powershell), and run an MSI that adds to the Path environment variable,, unless you do something yourself, your copy of that environment variable;e is not updated. You just restart the process (eg PowerShell).

I mean it's not impossible to do, Winget could do it.

It's not a winget issue though. Anything done would be a hack at best. Terminal already has a issue open about refreshing the environment block iirc

I agree with this. I forgot how powershell and terminals in windows are supposed to work, hence why I (and probably most people) got here.

It's not a winget issue though. Anything done would be a hack at best. Terminal already has a issue open about refreshing the environment block iirc

@Masamune3210  A hack would be vastly better than the abysmal and confusing experience we have. If you're going to pass the buck to a different team, you should link to the related issue. The closest I could find was an improvement for refreshing environment variables, which could be useful to us in implementing a fix but the fix needs to happen from winget's side. Most of the time people are not refreshing the environment variables, so it does not make much sense to do it constantly. Additionally the proposed solution of kicking the responsibility to terminal does nothing for people using windows server.
https://github.com/microsoft/terminal/issues/15102
@doctordns This is almost always false. Many problems are not addressed not because they are hard, but because they are lower priority. Software development has a triage process and breaking bugs and issues get first priority. This can mean that important but not required usability improvements go unaddressed, and if long enough even forgotten. User experience issues tend to be the items that are disruptive to use, but nonetheless never get fixed. We blame the users for being incompetent and move on. This sounds great until we ourselves are the users, and we ourselves have to remember little strange quirks for 80 different small applications that we use once every 3 years.
# too hard??? Really????
$Env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine")

@Hathoute If your users are routinely falling into a confusing trap, you should fix it. Winget in windows is supposed to work in an unsurprising way. This behavior is very surprising, as this thread indicates. We can say this is how it does work, but it is not supposed to work this way.

Also, FWIW, https://github.com/microsoft/terminal/issues/15102 is not the solution to this issue. That's tracking a perf improvement to the way that Terminal reloads env variables in 1.18+. In 1.18, the Terminal will reload environment variables when making a new tab (so you'll no longer need to quit out of the Terminal and restart). You'll be able to just open a new tab (or restart the connection).
But ultimately, there's no way for the Terminal to force a shell (cmd, pwsh) to update its own environment variables.

@voronoipotato :

# too hard??? Really????
$Env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine")

Even supposing that were possible (you would have to do that to a different process (the shell process)), you would be surprised how much stuff that would break: there are many systems out there that depend on environment customization from the parent process (so reading fresh values straight from the registry would wipe those out).
So what you would have to do is compute a diff: read the Machine and User values straight from the registry, do the install, read the values from the registry again, and compute the diff (and assume that if anything else was messing with the registry values concurrently, "it's fiiiine"). But then you still have the problem of adding the new stuff to the correct shell process.
However, your posting of PS script gives me an idea of a hack/workaround that may be both "good enough", and not so hacky/gross as to disqualify it as a legit step forward:
What if winget.exe also shipped with a winget.ps1 file next to it? When in powershell, if a user were to run winget, they by default would get the .ps1 before the .exe... so then the .ps1 could handle doing the path diff'ing and apply it in-process... @denelon, what do you think of that?

If it were easy, we;d have had a solution years (decades?) ago. I would argue winget is working as designed and this is not a bug.

Oh it's too difficult to solve. OK, nevermind then; didn't realize this would be hard to solve. Let's just forget the issue and deal with it then.

If it were easy, we;d have had a solution years (decades?) ago. I would argue winget is working as designed and this is not a bug.

Oh it's too difficult to solve. OK, nevermind then; didn't realize this would be hard to solve. Let's just forget the issue and deal with it then.

@jazzdelightsme,
That's an interesting idea. It's something we could experiment with.
The real challenge is the App Execution Alias for winget might get resolved before the .ps1. If we're running a PowerShell cmdlet we might be able to do that more cleanly than in the CMD.exe shell.

The real challenge is the App Execution Alias for winget might get resolved before the .ps1.

Ugh, I was thinking of resolution preference between e.g. .ps1 and .cmd (where .ps1 would win), but you're right that it would be a problem for .exe versus .ps1; my bad.
But having a winget command exported from a PowerShell module would take preference. It would have to be a "simple function" (as opposed to an "advanced function") so as to be able to function as a completely transparent stand-in for the winget.exe command.
However I think it is still worth considering dealing with %PATH% order, in order to also provide a similar .cmd solution for cmd.exe users. I.e. if we put winget.ps1 and winget.cmd files into C:\windows\system32, they should be ahead of the windowsapps alias EXEs on the PATH; and then if a user just says "winget" (instead of "winget.exe") then the right thing would magically happen in either shell. (Nobody likes putting more stuff into system32, but I think it is justified in this case.)

Could the exe possibly detect what terminal its running in and call into the .ps1 if it detects powershell?

Sadly, no. There is a distinction between the shell used to communicate with the kernel and the terminal used for rendering input/output. The winget.exe cli is being called in a process, and it doesn't have a reliable way to look up and see what called it. There are special cases that allow us to know when the PowerShell cmdlets are being invoked by virtue of the code being in a PowerShell module so that may be one area where we can relatively easily enlighten ourselves.

I'd be okay with a minimum viable product of "it works with powershell" , with cmd fix provided later.  I could tell my team, "Hey this is a temporary thing, but the experience is less confusing if you use it in powershell". It's not perfect but as a workaround for the immediate term it would still be very valuable. Thank you @denelon for being consistently supportive.

First, thank you so much for all the efforts made in this space. I want to share my opinion about this. As a first principle, making the package manager seamlessly install and make available the applications is its fundamental main use-case. Anything that hinders or adds obstacles to attain this goal is a barrier for adoption and a risk to the success of the project.
Think about your own out of the box experiences and how they affect your perception of a product.
I want to contribute to this conversation with some technical details that can assist with the implementation of such a feature:
To check if you are running on CMD, Windows Powershell or Powershell 7
(dir 2>&1 *`|echo CMD);&<# rem #>echo ($PSVersionTable).PSEdition
# Returns one of: CMD, Core, Desktop

To update the PATH variable from withing a CMD prompt
MSDN says:
To programmatically add or modify system environment variables, add them to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment registry key, then broadcast a WM_SETTINGCHANGE message with lParam set to the string "Environment".
This allows applications, such as the shell, to pick up your updates.
To reload the environment variables in powershell
$env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")

To set the PATH variable in all unix systems
export PATH=$PATH:the/file/path
set PATH=$PATH:the/file/path

As a bit of an explanation of why this is an issue with winget that other package managers don't have:
Unlike other package managers, winget doesn't have a package format like .deb, .rpm or .msix. Instead, what winget uses are the existing installers for applications, like .msi or .exe files. I remember seeing an issue that it shouldn't be called a "package manager" because of that.
With a package file we know the contents of and we manually place on the system, it's relatively easy to add a single directory to the path the first time, then put links there pointing to the known location of the installed executable. Then everything works right after installing since the new file is already on a directory on the path. And this is actually what happens with portable apps in winget.
But with an existing installer, we'd have to know if the installer needs something added to the PATH, whether it does it on its own, and then re-load the environment to have the PATH changes take place.
Another issue is that on Linux there are more standard paths that are already on the PATH, like /bin/, so you just put something there and you don't even need to edit the PATH. But on Windows, apps tend to go under C:\Program Files\<app>\, so you need to add the specific app to the PATH. (Though this wouldn't be a problem if we had actual packages.)
Doing things this way does cause problems, like this, or not being able to ensure clean uninstalls. On the other hand, it lets us work with existing apps without having the publishers repackage them. It also lets us manage apps that one has already installed on the machine, instead of only the ones installed through winget.
BTW, Windows already has a package manager/package format that guarantees a lot of the stuff one would want, for example clean uninstalls or having commands immediately available. That is MSIX, but it requires some effort to re-package an app into that format, so many popular apps are not available in that format.

Here's a full write-up of the key design constraints that I observe for a solution to automagically update the PATH environment variable in a user's shell, along with my suggested approach.
TL;DR: if you want to try my suggested solution, put the files at the bottom of this post into your C:\windows\system32 directory, and as long as you always say "winget" instead of "winget.exe", things will probably work as you expect (environment will be updated) in cmd.exe, powershell.exe, and pwsh.exe.
Also, first some important caveats:

I do not work on the winget team, nor do I have special visibility into their scheduling/priorities. I believe the standard place to point to for the question "when will this be addressed?" is this roadmap page and the milestones page.
They may choose a different approach (though it will necessarily be constrained as described below), and they may face additional design constraints or challenges (for example, though you can try my solution by dropping a few scripts into your system32 folder, I'm pretty sure the DesktopAppInstaller package can be installed without elevation, so they likely will not want to use that location). Though my proof of concept works great for things like nvim, I know that they face much more complicated situations/packages, too.
There may be additional work for them to do; for example, to figure out how to expose this as an experimental feature in order to evaluate the impact on a very large and diverse ecosystem.

With all that said, let's jump in.
The crux of the problem is that environment variables need to be updated in the user’s shell, which is going to be a different process than the winget.exe process. This leads to the main constraint for any possible solution:
Requirement 1: somehow, someway, there will need to be code that runs in the shell process.
Where does that code come from? One could imagine that it could be built into the shell itself: for instance, if pwsh.exe itself created a hidden window, in order to listen for WM_SETTINGCHANGE messages; upon receipt of said message, it could refresh its environment block.
But there are some problems with that:

Not all installers will broadcast a WM_SETTINGCHANGE message.

We could work around this by having winget.exe blindly broadcast it.

I’m not sure how well this might work in a service session (Session 0), where Windowing operations are more locked down.
Once the message comes, we know “something changed”, and we need to “refresh” our environment… but what exactly should we add? I will explain more about this below, but the most solid solution must do some kind of “diff” operation, and with the one-shot "something changed” broadcast, there is no clear opportunity to capture the “before” state.
Probably most importantly: not all shells will be willing to make this change.

In particular, cmd.exe and powershell.exe are incredibly unlikely to even consider such a change. They are frozen.

So in my mind that idea (code being built in to the shell itself) is a non-starter.
More about the “diff” problem: it is absolutely not a simple operation to “just refresh the PATH environment variable”. The PATH variables (I’m thinking specifically of PATH and PSModulePath) are stored in the registry, but you can’t just read the current registry value and say “well, that’s the current path!”, because it’s not. Many shells and environments, including powershell.exe and pwsh.exe, modify their PATH environment variables at runtime, depending on myriad and complicated factors. (Want a headache? Just try to figure out how powershell.exe and pwsh.exe heuristically update PSModulePath at runtime (it can become… problematic).) And it’s not just the shells themselves; many shell-based “operating environments” also perform heavy and critical customization of PATH-related environment variables. So you absolutely cannot “just read the current values from the registry” and apply them in-memory. Doing so would break approximately a million things.
So how could we update the environment, in as safe and non-breaking a way as possible? The critical thing is to not mess up any in-memory customizations, so ideally we just tack on the bare minimum of “what actually changed” onto the very end. (It’s possible that an installer does something super fancy, and purposefully updates %PATH% to stick something new in the middle, before some other paths; but I think that’s a rare case, and getting it wrong by updating the current process’s PATH to add the new thing at the very end is at least still not disruptive to any other existing in-memory customizations.)
This is what gives rise to:
Requirement 2: There has to be a “diff”: we need to know what actually changed, so we can add just that to the end of the current, in-memory value.
So we have to compare a “before” and “after”… and with the WM_SETTINGCHANGE broadcast there is no clear “before” point. Trying to compare an in-memory, potentially highly customized value to what’s in the registry, with no frame of reference, is doomed to be extraordinarily fragile and impossible to get completely right. Like a three-way merge without the “base”.
Okay, back to requirement 1: we have to have code that runs in the shell process. How can we do that? I see only two options:

Invasively inject a thread into the shell’s process.
a. This is a nuclear option. The CreateRemoteThread API is one of those scary APIs with documentation that says things like "the application can deadlock if the thread attempts to obtain ownership of locks that another thread is using". Given that we have a narrow list of shell processes to target, it could probably be made to work… but it's a pretty serious thing to go injecting code into an unsuspecting process.

a. For cmd: a .cmd/.bat script.
b. For PowerShell: a .ps1 script.
c. Bash: a .sh script.
d. Etc.
e. Because winget is Windows-specific, just handling cmd and PS is good enough; who in the world is running winget commands from bash, amiright? :D

Okay, so we’re going to have a script.
This brings us to the last piece of the puzzle: how is the [shell-specific] script going to get executed in the proper shell process? Winget.exe can’t do it directly (and don’t say CreateRemoteThread again)…
Easy: just have the user do it! :D
We train people to just run “winget <arguments>”… but that does not have to directly be winget.EXE. If we have winget.ps1 and winget.cmd, which come before winget.exe on the %PATH%, then when you are in cmd.exe, and you run “winget”, you will run winget.CMD; when in pwsh.exe, you will get winget.PS1.
And here’s what the script will do:
1. [If we are doing an "install",] read the current PATH values out of the registry (the “before” snapshot). This is possibly very different from what’s in memory, but that’s okay; this is just a reference point to find out what the installer has actually changed.
2. Run winget.exe, passing through all arguments (%*/$args).
3. Read the current PATH values out of the registry (the “after” snapshot), compare to “before” to see what the installer changed, and tack the additions onto the end of the in-memory environment values.
Et voilà!
(This is actually a pretty standard trick; to wrap things in a script wrapper for various reasons.)
If you want to try this out, a convenient, guaranteed-to-exist-and-be-on-the-PATH-and-come-before-the-windowsapps-dir path is C:\windows\system32. So you can put the script files below into system32 as an easy way to evaluate this, but remember that this is probably not an attractive "real" solution for the winget package (which means somebody needs to do some work to arrange for a different, user-specific (so it won't require elevation) path to be on the %PATH%, before the windowsapps dir (where the winget.exe command is found).
(Also, note that you don't actually need the .Tests.ps1 file; that's just test code, which is convenient if you want to play around with it. Note that it requires you to install Pester v5.)
Script files:
winget.cmd:
@ECHO off
SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION

REM This wrapper script is a straight "pass-through" to winget.exe, and then after running
REM an install, it will update your in-process PATH environment variable.

IF "%1" == "install" (
    SET TheHelperCommand=powershell.exe -NoLogo -NoProfile -ExecutionPolicy RemoteSigned -Command . %~dp0wingetHelper.ps1 ; GetStaticPathFromRegistry PATH
    FOR /F "tokens=* USEBACKQ" %%i IN (`!TheHelperCommand!`) DO (
        SET StaticPathBefore=%%i
    )
)

winget.exe %*

IF NOT "%StaticPathBefore%" == "" (
    FOR /F "tokens=* USEBACKQ" %%i IN (`!TheHelperCommand!`) DO (
        SET StaticPathAfter=%%i
    )

    SET TheHelperCommand=powershell.exe -NoLogo -NoProfile -ExecutionPolicy RemoteSigned -Command . %~dp0wingetHelper.ps1 ; CalculateAdditions 'PATH' '%StaticPathBefore%' '!StaticPathAfter!'

    FOR /F "tokens=* USEBACKQ" %%i IN (`!TheHelperCommand!`) DO (
        SET Additions=%%i
    )
    REM ECHO Additions are: !Additions!
)

IF NOT "%Additions%" == "" (
    ENDLOCAL & SET PATH=%PATH%;%Additions%
)

winget.ps1:
# This wrapper script is a straight "pass-through" to winget.exe, and then after running
# an install, it will update your in-process Path environment variables (in your current
# shell).
#
# N.B. This is a "simple function" (as opposed to an "advanced function") (no
# "[CmdletBinding()]" attribute). This is important so that the PowerShell parameter
# binder does not get involved, and we can pass everything straight to winget.exe as-is.

try
{
    $pathBefore = ''
    $psModulePathBefore = ''
    if( $args -and ($args.Length -gt 0) -and ($args[ 0 ] -eq 'install') )
    {
        . $PSScriptRoot\wingetHelper.ps1

        $pathBefore = GetStaticPathFromRegistry 'PATH'
        $psModulePathBefore = GetStaticPathFromRegistry 'PSModulePath'
    }

    winget.exe @args

    if( $pathBefore )
    {
        UpdateCurrentProcessPathBasedOnDiff 'PATH' $pathBefore
        UpdateCurrentProcessPathBasedOnDiff 'PSModulePath' $psModulePathBefore
    }
}
catch
{
    Write-Error $_
}

wingetHelper.ps1:

# Split out for mocking.
function GetEnvVar
{
    [CmdletBinding()]
    param( $EnvVarName, $Target )

    # (the cast is so that a null return value gets converted to an empty string)
    return [string] ([System.Environment]::GetEnvironmentVariable( $EnvVarName, $Target ))
}

# Gets the "static" (as stored in the registry) value of a specified PATH-style
# environment variable (combines the Machine and User values with ';'). Note that this may
# be significantly different than the "live" environment value in the memory of the
# current process.
function GetStaticPathFromRegistry
{
    [CmdletBinding()]
    param( $EnvVarName )

    (@( 'Machine', 'User' ) | ForEach-Object { GetEnvVar $EnvVarName $_ }) -join ';'
}

# Split out for mocking.
function UpdateCurrentProcessPath
{
    [CmdletBinding()]
    param( $EnvVarName, $Additions )

    Set-Content Env:\$EnvVarName -Value ((Get-Content Env:\$EnvVarName) + ';' + $additions)
}

function UpdateCurrentProcessPathBasedOnDiff
{
    [CmdletBinding()]
    param( $EnvVarName, $Before )

    $pathAfter = GetStaticPathFromRegistry $EnvVarName

    $additions = CalculateAdditions $EnvVarName $Before $pathAfter

    if( $additions )
    {
        UpdateCurrentProcessPath $EnvVarName $additions
    }
}

# Given two strings representing PATH-like environment variables (a set of strings
# separated by ';'), returns the PATHs that are present in the second ($After) but not in
# the first ($Before) and not in the current (in-memory) variable, in PATH format (joined
# by ';'). (Does not do anything about removals or reordering.)
function CalculateAdditions
{
    [CmdletBinding()]
    param( [string] $EnvVarName, [string] $Before, [string] $After )

    try
    {
        $additions = @()
        $setBefore = @( $Before.Split( ';' ) )
        $currentInMemory = @( (GetEnvVar $EnvVarName 'Process').Split( ';' ) )

        foreach( $p in $After.Split( ';' ) )
        {
            if( ($setBefore -notcontains $p) -and ($currentInMemory -notcontains $p) )
            {
                $additions += $p
            }
        }

        return $additions -join ';'
    }
    finally { }
}

wingetHelper.Tests.ps1:
BeforeAll {
    $parentDir = Split-Path $PSCommandPath -Parent

    . $PSCommandPath.Replace('.Tests.ps1', '.ps1')

    function ResetFakeRegistry
    {
        $script:FakeRegistry = @{
            User = @{
                Path = ''
                PSModulePath = ''
            }
            Machine = @{
                Path = 'testPath1;testPath2;testPath3'
                PSModulePath = 'testPsModulePath1'
            }
            Process = @{
                Path = 'testPath1;testPath2;testPath3;runtimePath1'
                PSModulePath = 'testPsModulePath1;runtimePsModulePath1'
            }
        }
    }

    Mock GetEnvVar {
        return ($script:FakeRegistry)[ $Target ][ $EnvVarName ]
    }

    Mock UpdateCurrentProcessPath {
        # (nothing)
    }

    # Hide the real winget.exe:
    function winget.exe
    {
        # (nothing)
    }
}

Describe 'winget.ps1' {
    BeforeEach {
        ResetFakeRegistry
    }

    It 'should do nothing if not an install command' {

        # N.B. Dot sourcing here is important, so that it executes in the current scope.
        . $PSScriptRoot\winget.ps1 some other command

        Should -Invoke -CommandName 'GetEnvVar' -Exactly 0
        Should -Invoke -CommandName 'UpdateCurrentProcessPath' -Exactly 0
    }

    It 'should do nothing if no change in path' {

        # N.B. Dot sourcing here is important, so that it executes in the current scope.
        . $PSScriptRoot\winget.ps1 install something

        Should -Invoke -CommandName 'GetEnvVar' -Exactly 10
        Should -Invoke -CommandName 'UpdateCurrentProcessPath' -Exactly 0
    }

    It 'should update current process paths if install updated paths' {

        $newPaths = 'newPath1;newPath2'
        $newPsModulePaths = 'newPath3'
        Mock winget.exe {
            # Simulate install updating the registry:
            $script:FakeRegistry[ 'User' ][ 'PATH' ] = $newPaths
            $script:FakeRegistry[ 'Machine' ][ 'PSModulePath' ] = $newPsModulePaths
        }

        # N.B. Dot sourcing here is important, so that it executes in the current scope.
        . $PSScriptRoot\winget.ps1 install something

        Should -Invoke -CommandName 'GetEnvVar' -Exactly 10
        Should -Invoke -CommandName 'UpdateCurrentProcessPath' -Exactly 1 -ParameterFilter {
            ($EnvVarName -eq 'PATH') -and ($Additions -eq $newPaths)
        }
        Should -Invoke -CommandName 'UpdateCurrentProcessPath' -Exactly 1 -ParameterFilter {
            ($EnvVarName -eq 'PSModulePath') -and ($Additions -eq $newPsModulePaths)
        }
    }

    It 'should not add duplicate paths' {

        $newPsModulePaths = 'newPath3'
        $script:FakeRegistry[ 'Process' ][ 'PSModulePath' ] = $newPsModulePaths
        Mock winget.exe {
            # Simulate install updating the registry:
            $script:FakeRegistry[ 'Machine' ][ 'PSModulePath' ] = $newPsModulePaths
        }

        # N.B. Dot sourcing here is important, so that it executes in the current scope.
        . $PSScriptRoot\winget.ps1 install something

        Should -Invoke -CommandName 'GetEnvVar' -Exactly 10
        Should -Invoke -CommandName 'UpdateCurrentProcessPath' -Exactly 0
    }
}

(I forgot to add: a small downside to the "script wrapper" approach is that if someone runs "winget.exe" instead of "winget", then they don't get the magical path-refresh behavior. But there's a very good upside to this: it means that if there were some targeted situation where you didn't want path refresh, you could avoid it by just running winget.exe instead.)

Good news, at least in the realm of stop gaps, Terminal now has the ability to get a new environment block on tap open, at least in preview. At least we don't have to close the whole terminal anymore, just opening a new tab should be enough

I do suggest closing the "first" tab though, I've confused myself more than once switching to a different tab that hadn't been updated.

@denelon Do you think we'll get this for powershell users in the near future?

Thanks for the update :). I understand that there's a lot of important work but I'm grateful that it's being treated as a priority.

I do suggest closing the "first" tab though, I've confused myself more than once switching to a different tab that hadn't been updated.

Not a bad idea, I see how that would get pretty confusing. I get confused enough just having multiple types of processor in the same window lol

In an idle moment, it occurred to me that there is another way you could arrange for the wrapper scripts to take precedence over the EXE, without having to fiddle with %PATH%, if you were, hm, not sure how best to describe it... willing to take drastic action in service of the user, maybe?: you could rename the EXE (e.g. winget-real.exe, or maybe winget-cli.exe, ha) (and add additional wrapper scripts named winget.exe.cmd and winget.exe.ps1 in order to keep invocations of winget.exe working).
The price (what would stop working) is anything that expected "winget.exe" to be an actual PE file (like someone using CreateProcess( "winget.exe", ... ) directly, instead of ShellExecute or such). I would expect such usage to be very low. (There would still be a "don't want the wrapper script" workaround; it would be to just call winget-real.exe instead.)
What is most interesting (to me) about this thought experiment is the utter revulsion I feel about renaming the EXE. Why does it seem so gross? From the point of view of the end user, I think that they don't care at all (99.9% wouldn't even notice); they just want to run "winget install whatever" and have it work. So why does renaming the EXE just so these shell wrapper scripts can take precedence feel like some kind of violation? It makes me wonder if I am holding things sacred that I should not be.

We do have plenty of cases where the MSIX behavior isn't what customers want, and they are sensitive to changes in the name of the "primary" executable. If this does actually end up being the right thing to do to resolve the challenges associated with path, it might be OK though.
Several users have automated solutions calling winget.exe directly in the path where the files get laid down rather than using the App Execution Alias that typically catches "winget" via Windows Terminal, PowerShell, or what ever shell they happen to be using.

Our preference for integration is to call the COM API rather than winget.exe. In the case of PowerShell users, I think we could just make that work as we would like, but we'll have to continue investigating.

I am not sure if this is the same issue but I am observing this behavior :

The same applies with Powershell.
Everytime I start cmd or powershell binaries installed with winget seem not to be in PATH, I click on new tab, then I can use the binaries ...

@amoscatelli    Winget does not currently refresh the path. It is still effectively in alpha from a UX perspective. It can be used, and is stable, but until this issue is fixed I would not recommend it to anyone other than power users who want to play with something new. It's too confusing and will make people resent an otherwise pretty good tool.

It's an alpha just because it doesnt do something that most programs also don't do? Outside of choco and scoop, I'm not sure people realize just how rare it is to find a program that supports regenerating the environment block after process creation.

I can't think of any another package manager that fails to do this, so yes it's very unexpected behavior, so yes it's alpha.

That's.....not how product dev tiers work, but ok. Other package managers also don't directly query the system for installed programs or try to do everything by the books instead of relying on tricks.

I understand that this product is doing cool new things, and I think that's great. I also understand that an app that breaks the user flow entirely is not ready for beta. People would attempt to use it, say it doesn't work, and then not use it again. Software that can't be used without a testing script is in alpha, even if it is for usability reasons.

I really do not understand the real issue. If you run any installer from the command line/powershell, I never assume the path will get updated (in the current session). When the installer finishes, I open up a new shell and move on.  I wonder how much workflow is predicated on that approach.  For me, Widget's behaviour is consistent and expected., After installation completes, one just opens a new shell. and everything works as it should. For me, Windows has always worked this way - or is my memory faulty?
So far as PowerShell is concerned, I am unsure how Winget could force an update to the path variable ($Path) within the current PowerShell session. As an aside, providing such a general mechanism within PowerShell also might be a security risk.

Literally every other package manager inside or outside of windows works in this way, so it's surprising to nearly everyone who has experience with the thing.

Neither chocolatey nor scoop regenerate the environment block, and anything outside of on Windows is completely missing the point.

Completely missing the point? And what exactly do you think the point is here? Because to me the point of winget is to make feature parity with other major OSes and moreover to make the user experience easier. So what Windows has historically done is irrelevant and what other OSes do is exactly the point.
And further, why even argue against this improvement? If it gets implemented, you lose nothing. There's obviously a lot of people who are confused by this, so it must be a worthwhile addition.

I'm not arguing against the improvement. If you actually paid attention, I am in the early parts of this very issue talking about things being worked on in relation to this and commenting on ways to handle it once it is. What I am arguing against is people making a bigger deal out of it than it really is. Yes, its quite annoying that you have to open a new shell to get anything that you installed to actually work. Yes, I get that it can be confusing. But when people actively start to bemoan the entire project as useless solely because of a single troublespot, it gets old real fast.

Well that's what happens when I try to share it with anyone, so I don't. I'm not here in the comments because I don't like the project, I'm here because I like it but I can't actually share it because anyone I share it I'd have to explain around the very first step of using it. It's not a dealbreaker for me using it, but it is definitely a dealbreaker for sharing it with others.

I am having difficult understanding why needing to restart a shell after running an installation tool that updates the system path. This, to my memory, has never been the case with Windows.  Somehow, saying this is a huge major catastrophic deal breaker seems a tad over the top! ;-)  I have seen zero evidence that this is actually any soft of major issue although I could be looking in the wrong place.
I am not even sure how winget could do this.at least for PowerShel - and if it could, it would certainly be a security risk. Can you suggest how this could be done? Because I can not see any way that is both NOT a hack and NOT a security risk.
My suggestion if this the team close this issue as either Won't' Implement or By Design.

Convenience matters a lot with adoption! Painful automation means people won't use it.

It's surprising anyone needs convincing that being able to do the following is useful:
winget install foo
foo

Yes, having to start a new shell after I install an app won't kill me.
Yes, my PS script having to do $env:Path = [System.Environment]::GetEnvironmentVariable("Path", "Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path", "User") whenever it needs to run an app it just installed won't kill me.
But we can all see why not having to do these things would be convenient, right?

With that said, the claim that winget is an unusable mess just because the PATH updates are not immediately visible within the current session doesn't really resonate with me. The main functionality of a package manager is to manage packages, i.e., find, install, update, and uninstall them. winget does all these, and the fact that it's not as convenient as others yet doesn't make it alpha.
So, I disagree with both the "this feature is useless" and the "this app is useless" arguments. winget is great as it is but there's always room for improvement, and this one would be a pretty big improvement for how I use winget.

I agree fully. Everything can always be better, but that doesn't mean that it isn't already good

Sure, it would be nice. But it really doesn't affect me after 30 years of using Windows and nothaving it.  :-) I have never used it and frankly, a new shell is also useful for other reasons. SOME packages update the $Profile, so the best way of using the new app is to restart Psh. I get that a few users want something better (and sure it would be nice) but it probably won;t h appen.
If you really want this feature, then first show how winget can affect the $Path variable within the PowerShell process. Maybe I am missing something but I can't see how it could be done.  I am pretty sure the Winget process spawned from PowerShell can not affect the calling process (i.e. PowerShell).
I suspect PowerShell could have an API added to enable this, but it would be a wide-open security risk. And messy - do you really want $Profile to be re-executed.

Lock environment block regeneration behind UAC. That way, if you want it, you need perms. If you have a UAC bypass circumstance, you have worse issues to deal with than just being able to call from an open terminal or not

For what its worth, there IS actually progress being made to help out with that, even though it might seem otherwise. If they are using Windows Terminal, you don't have to close the whole terminal, just open a new tab

Right, which I can tell them "Oh just use windows terminal". Though I'm excited about this fix getting implemented at least for powershell. That way I can say "Oh just use powershell". Since if you're not using the default experience it's much more reasonable that you might need to add a shim like safakgur mentioned, and I don't think that's as critical of an issue.

But it really doesn't affect me after 30 years of using Windows and nothaving it.

This is the exact attitude that bothers me so much. "It's always been that way so we should just leave it be." We're trying to improve a product in here; if you're going to be a nay-sayer go somewhere else. Just because you never use it doesn't many no one else does.
And what you've done in the past is irrelevant. We also use to trust SHA-1 and didn't have MFA. Times change and until winget makes feature parity, it will be another excuse for linux fans to reject Windows as a competitive option.
I'm NOT suggesting we forgo security to make it work; I just think it's ridiculous to look at a problem and say "nope, can't be done."
If you come to the conversation with a list of problems and no solutions, you're just a complainer.

Fanatics don't need an excuse to trash on Windows. That's kind of part of being a fanatic lol

Can we please not be dismissive? Many people who are fans of linux also are fans of windows. It is not the year 2000, people are allowed to like more than one thing. In fact I'd argue pushing for improvements is more of a sign of being a fan than moping about how something isn't possible to fix (not to say that you've been doing that). I wouldn't have said anything if this weren't a serious UX issue, I'm not cruel. I do like linux, but I also care about Microsoft continuing to exist. We're all poorer with fewer options in the market. Right now I think the package manager is one of the largest advantages linux has over windows server and I think this glaring UX issue makes winget look broken to anyone trying it out. It's depressing to me that Microsoft isn't putting more resources into this and makes me afraid that in the future we're going to have a duopoly of IBM and Canonical for server operating systems with support.

I wasn't being dismissive. Fan is literally a shortened form of the word fanatic. Someone who is fanatical about something is, by the very definition of the word, not going to be that logical in their decisions.
Btw, on latest versions of Windows, Terminal should already be the default, with the legacy individual terminals being moved to a holdover legacy option

I hope you appreciate "I never needed it in N years :-) let's close it as Won't Implement" sounds way less reasonable than "This requires changes outside winget, so we're blocked until that happens".

I'd be grateful if those advocating this feature could explain how it could be implemented just within Winget.

With shims! Manifests can allow specifying executable names that we want in PATH, and winget can put shims of those executables to a folder that's already in PATH. That's a problem solved years ago by choco and scoop.
I left https://github.com/microsoft/winget-cli/issues/549#issuecomment-1369959015 here 7 months ago. I'm not sure what's the state now, but we needed two things back then:

Ability to specify what to shim in the manifests.
Shims to use junctions, like scoop, rather than symbolic links, as symbolic links require elevated privileges to create.

I see we also have #361 to track shims but it doesn't seem to have much traction.

This issue's been open for 3 years and I get emails for this thread frequently. The conversation keeps going in circles about how it's not the role of the package MANAGER to manage the dang package! This is far from true of EVERY other package manager I have ever used for any system or language, ever. I have never had to go hunt things down after they were "installed" because they've always worked as expected. The only one that's not in line here is winget, and it makes me think about POLA (Principle of least astonishment).

In user interface design and software design,[1] the principle of least astonishment (POLA), also known as principle of least surprise,[a] proposes that a component of a system should behave in a way that most users will expect it to behave, and therefore not astonish or surprise users. The following is a corollary of the principle: "If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature."[4]

see also

For those parts of the system which cannot be adjusted to the peculiarities of the user, the designers of a systems programming language should obey the “Law of Least Astonishment.” In short, this law states that every construct in the system should behave exactly as its syntax suggests. Widely accepted conventions should be followed whenever possible, and exceptions to previously established rules of the language should be minimal.

I know this isn't actual law, but having to play find the needle in the haystack with software I got through winget isn't what I expect from a package manager - the package manager is supposed to let me pick a package from a repository, install it, and be able to use it after install. Winget does 2/3 of those things. As a user, I couldn't really care less how this is handled semantically; I just want those programs to be callable! Not a single thing I have ever installed through winget has been callable after install even if I opened up a new shell. I've had to look for Every package and add them all to path myself, --info is supposed to show me install locations, among other things, and I'm not even seeing my package in those directories, --location is supposed to let me at least pick the location the package is installed to and that didn't work for me! So now here I am, having to play find the needle in the haystack with ffmpeg and thinking about POLA, and this specific Issue.
The thing I really admire about technology is that there's never only one perfect way to solve an issue, there are always multiple options that can be used to achieve a given goal. This is true on both ends, you have multiple options you can try to work with, and I have other package managers I could try that work as expected. I'd rather have SOMETHING that's good, than wait around forever for something to be perfect. I don't need perfect, and no one here is asking for perfect or really even being too picky about the implementation.
Anecdotally, I'm using a different computer and the Chocolatey package manager was FAST to install, it installed ffmpeg quickly for me, and I didn't even have to start a new session to call it. This is a package manager working as expected, this is the kind of result I want to see. Chocolatey used a shim, I do not care that they used a shim, they didn't get bogged down with the semantics like we're seeing here they just did Something! Seeing how fast and simple Chocolatey was to setup/use, I don't really see myself coming back to winget and am just going to put Chocolatey on all my home and work systems for future use, and if asked about a good Windows package manager that'd likely be my go-to because yeah if I'm being honest with them and knowing what they expect from a package manager why would I, or anyone, recommend winget over anything else that does what people expect a package manager to do.
I want to be sympathetic here, but every time this Issue looks like it's going in the right direction and we landed on SOMETHING to try, it gets steered back to the position that winget is not responsible for making things callable after install - and that this is the job of the package maintainers themselves. I don't really have the energy to care about this anymore given I found a good solution, but figured this feedback is important to share nonetheless. There is a lot of valuable user feedback and genuine good faith attempts at trying to find a solution in this thread that is not being fully appreciated and these people are working with you for free and unsolicited because they want this to succeed. I do too, but I can't really wait for it.

A long response but while the POLA is an interesting justification, Snover's First Law trumps it. To ship is to choose  and in 3 years the Winget team has indicated no interest in implementing  this, and almost zero support elsewhere. And o see zero interest from those who could implement it. In my experience guilt tripping rarely works.
But if you want it, then explain how it could be implemented. I know of no way running an executable in PowerShell that can cause the environment block refreshed (and $profile to be reexecuted). And even if it could be, it would seem to be a security hole.
I see little hope of winget doing this on its own. You would need to change PowerShell and Windows Powershell. And I see zero chance of updating powershell to implement this (and an even lower chance of backporting it to Windows PowerShell. I could be wrong, but I simply see inadequate support.

@doctordns You could argue every issue in every repo is not possible because you do not know how to do it. Your own lack of knowledge is not a counter argument.  You have ignored all the approaches already proposed in this thread. Either educate yourself on why this is possible, feasible, currently in use, and make more nuanced critique of a specific approach or stop spamming this thread. There was support by @denelon a few months ago when we workshopped some ideas. It is on the vnext-client backlog for a reason. If we can instead use this issue for discussion upsides/downsides of specific approaches and get affirmation around which path the lead wants to go we can start actually implementing it.

It requires admin access to install, which is unfortunate, but even so I think it could make things a lot more convenient for a lot of people, so I went ahead with it. You can try it out by:
winget install WingetPathUpdater # <-- this is the thing

# Now this will work:
winget install nvim
winget install Microsoft.VCRedist.2015+.x64  # this is missing from the nvim package :(
nvim  # ta-da!

We're working to get dependencies out with WinGet 1.6 (ETA end of September). A couple of weeks after that we will start automated validation with dependencies in earnest.

#163

This is awesome!! thanks @jazzdelightsme for your hard work and thank you @denelon for supporting this. Very exciting :)

If you have problem installing commands from pip, try adding the following directory to your PATH.
%LocalAppData%\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\Scripts

@mon-jai
This issue is not specific to packages which execute global commands to pip.
I have had this issue with a number of packages. WingetPathUpdater does present good information and a possible solution (https://github.com/jazzdelightsme/WingetPathUpdater#readme), however IMO a solution does not exist yet for this issue.
Even some kind of prompt would be helpful - "Warning: this package will not executable using its alias [alias] until the shell is restarted." I would note this includes any shells that may be open within VS Code etc.

Stumbled upon this package that have cli version but installer does not add it to PATH https://github.com/microsoft/winget-pkgs/tree/afaf1950df18389dcf43dcdb43e9c5673f58fce0/manifests/p/PragmaTwice/proxinject

https://github.com/microsoft/winget-cli/issues/4008

Great news!
https://blogs.windows.com/windows-insider/2024/02/14/announcing-windows-11-insider-preview-build-26058-canary-and-dev-channels/
Search for "winget" on that page.

[Command Prompt]
If you run winget, or any other package manager configured to do so, Command Prompt (CMD) will now look for changes to the PATH and update your current session. To enable a package manager to have this logic in CMD, simply add the package manager .exe name to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor\KnownPackageManagers.

Note: This has not been implemented in PowerShell.

Amazing!!

@denelon This is indeed good news, but many programs don't add themselves to the PATH at all - we still need a solution for these (expecting all programs to remember to do this isn't realistic).

In the meantime, use the --interactive flag and click the .bat file checkbox per https://github.com/microsoft/winget-pkgs/issues/656#issuecomment-1284415659
winget install --id vim.vim --interactive

It isn't refreshing my shell after the installation, also in vscode if I don't close those windows the shell isn't refreshed inside it.

Great news!
https://blogs.windows.com/windows-insider/2024/02/14/announcing-windows-11-insider-preview-build-26058-canary-and-dev-channels/
Search for "winget" on that page.

[Command Prompt]
If you run winget, or any other package manager configured to do so, Command Prompt (CMD) will now look for changes to the PATH and update your current session. To enable a package manager to have this logic in CMD, simply add the package manager .exe name to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor\KnownPackageManagers.

Note: This has not been implemented in PowerShell.

The PowerShell team has spec'd this change and is evaluating with impacted teams. I don't have a date to announce, but we plan to include this in the future.

I made this PowerShell script for solving the path problem when using winget to install. It makes a persistent symlink so that I don't have to change my vim path in my git config.
https://gist.github.com/eggbean/351982f02f0ce7203669ac5ee05d7a06

@denelon we're still experiencing it for Godot even when we close terminal entirely and reboot any tips?


UI: Update and fix Claims component.

is this related to #1565 ?

@0reo nope, this was about general clean up.
but not relevant now cause moving to character-panel.


No methor found : groupMetaData | org.apache.kafka.clients.consumer.ConsumerGroupMetadata

I am writing a prototype application using parallel consumer and will be consuming an avro record as "GenericRecord", for that I had to use the property value.deserializer=io.confluent.kafka.serializers.KafkaAvroDeserializer. for this to work I had to use in build.gradle implementation 'io.confluent:kafka-avro-serializer:5.3.0'.
Due to this org.apache.kafka.clients version is changed from 3.3.0 to 5.3.0 and I am getting an error like no method found groupMetaData | org.apache.kafka.clients.consumer.ConsumerGroupMetadata.
Could you please help me with the work around to handle this issue.

I tried using implementation 'io.confluent:kafka-avro-serializer:3.3.0 but with started getting another exception Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/Jackson/JsonNode

Hi @dixitsingla - it really sounds like dependency issue - can you try to work out appropriate dependencies without Parallel Consumer first to work out kafka-clients + Deserializer ones that you need for your application?
Next step i guess would need to work out dependency exclusions to make sure the transient dependencies match.
If you can post your dependency graphs on working mini app using plain KafkaConsumer and then on Parallel Consumer i can have a look to reproduce and advice.


questions about the data distribution

hello! I have a question about the kernel dense eastimation part
What methods was used in drawing image distribution of labeled data and unlabeled data?

How can I analyses my own medical image dataset distribution

hello! I have a question about the kernel dense eastimation part What methods was used in drawing image distribution of labeled data and unlabeled data?

Hi! We use seaborn.kdeplot to plot the figure. For analysis, you can select pixels (or network's feature) of labeled data and unlabeled data belong to the same class and then draw them.


v6.2.0

Adds ability to start UICircularTimerRing from a value other than 0, as requested in #184

closes #184

Force merging this since travis is being dumb.