text:
Uninstall an installed App

As a user I want to be able to use winget to uninstall a package so I don't have to go through the Add/Remove software UX.
Note:
There are limitations about how programs get installed and whether or not that binary supports uninstall. This may also need to be supported in the manifest with new key(s) and or syntax.

This is never going to happen since packages just consist of random executable files that can do whatever they want. There's no package building step or anything.

Chocolatey (and scoop in certain scenarios) already does it through running the uninstaller that is registered in the control panel, I thought. winget could do a similar thing, although the flags for a silent uninstall would have to be in the manifest somewhere.

IMHO this is basic functionality which is paramount for the success of winget.

This is never going to happen since packages just consist of running random executable files that can do whatever they want. There's no package building step or anything.

There could be references to the programs' "uninstaller" executables as well.
For example, it could launch C:\Program Files (x86)\Steam\uninstall.exe to uninstall Steam.

The uninstaller reference comes with every installation. There are RARE cases of applications that cannot be uninstalled this way but it is doubtful they will be ever accessible / installable via winget.
Other than that you can clearly uninstall all apps using a WMI call and I have even borrowed a method someone else that is even able to crawl the registry for uninstalling applications by a name or wildcards.
Without blaming anyone, I certainly support an /u --uninstall switch, which can also be combined with /h --silent

in terms of naming i would not use Winget remove, imho as it is "install" it should be named "uninstall" for ease of use. https://github.com/microsoft/winget-cli/issues/192

i support it

For clarification about what I meant with my (admittedly flippant) comment above, see these three threads:

https://github.com/microsoft/winget-cli/issues/223
https://news.ycombinator.com/item?id=23238051
https://www.reddit.com/r/programming/comments/gmqv6n/microsoft_announces_the_windows_package_manager/fr5pasi/?context=3

Basically, my point is that since this works by running arbitrary exe files on the host computer, the only thing it can do to uninstall something is run another arbitrary exe, again pulled from 3rd party sources. That exe can do anything, especially not clean up all the crap left by the install process.
What you expect from package managers (coming from other OSs) is that they build packages that are pretty much just declarative file archives with as little logic as possible, then those are installed with logic defined almost completely on the side of the package manager instead of the to-be-installed app. The logic that comes with the package itself is minimal if it exists at all, runs at specific times with specific functions (preinstall / postinstall / etc) and is declared as readable code (e.g. shell scripts). The package manager or user then can also verify that the package does not do anything weird like copying files to unusual locations or removing other files, or setting up / starting system services. (that's also a job of the package manager).

Yes in fact whatr you are describing is something like MSI or MSIX / Windows Store that allows an internal uninstall via WinGet while at the moment and forseeable future winget is just the commandline (now also GUI) proxy for this task, but relies on some of the mentioned packagers and installation methods.

I don't understand, if one of the intents of this program is to let allow you to install pre-existing software as well as any packages it may have.
Is it not possible to run an installer in a kind of sandbox and track installed files?
Projects such as Nix, GNU Stow and Arch packages ect ect have worked hard to provide similar functionality with streamlines the proccess with the only difference being that almost always programs are explicitly made to interface with this proccess.
Would it not be possible to achieve similar funcitonality with this?
There might be some issues with cleaning up files after the installation proccess, but this is a problem that no package manager (that I know of) has solved, and a package manager like this in it's early development could look to solve it, especially since it is official some of this functionality could be facilitated with the kernel.

This is basic functionality for a package manager really. Without that we have something that is just barely above a powershell script or even a good ol' batch file.

I have an early draft started of the spec.  I am not tackling the notion of a sandbox at this time.
#397

SystemAppId is not enough to provide a proper uninstall experience IMHO.
There might be a need for a UninstallSwitches section with at least a Silent entry in the manifest. Unless we want to assume that all uninstallers support the same silent switch as its installer?
It would also be nice if winget tried the de facto standard QuietUninstallString registry value (if it exists) before using UninstallString.
When it comes to actually running the uninstaller, it is a good idea for winget to use a Job object on the uninstaller process so it can wait for all the children like Add/Remove programs does.
If you don't want to use a job object but still want to wait for the process then custom actions are required. For nullsoft this means using its special uninstaller syntax. In a batch file that would look something like this:
@echo off
REM This is a ugly mess because it is very hard for a running .exe to delete itself on Windows.
set "installdir=c:\program files\foo"
set "uninstbin=%installdir%\uninstaller.exe"
call "%uninstbin%" /S _?=%installdir%
if errorlevel 1 goto failed
del "%uninstbin%"
rd "%installdir%"
:failed

This is never going to happen since packages just consist of running random executable files that can do whatever they want. There's no package building step or anything.

That's just silly. -- If the package registry can specify an executable which can be run to install a given package, then it should be able to specify an executable that can be run to uninstall a package.
BTW, upon doing a quick search, it looks like package manifests are just yaml files -- so someone does have to build them -- apps don't just automatically have yaml files for no reason.  And if you can put an "Installers" key in your yaml file, you can sure as heck add an "Uninstallers" key with the exact same info. 😑

I agree with @BrainSlugs83 you can have contributors declare an uninstall key, that the program just executes, just like Homebrew formulae does, so you can have "if the user wants to uninstall do this: blah blah blah" and it would work without issues imo.

@sredna I understand your point of view. In fact, the approach you are suggesting -- giving the package manager real control over what installs where, as opposed to simply running an exe that pinky-promises to do so -- has already been tried. Scoop package manager is designed to work this way, and in fact most of its large catalog consists of "true" packages -- that is, Scoop just downloads and unpacks app files to a specific folder, without any arbitrary binary running. (...until you run the program that is...) Scoop achieves this by a collection of tricks and hacks, including specialized tools to unpack installers and creating symlinks for persistent files. I like this approach a lot, but it can be limiting for "real-world" applications -- although this works perfectly for Python, there is no way you could install Steam the "Scoop way". Also, this means that manifests for Scoop apps can get much more complicated than WinGet manifests.
I personally think that WinGet should support both types of installation -- prefer "real packages" where possible, otherwise revert to dumb "run exe". In fact, that's what WinGet does now -- MSIX is a "real package" format, and it can even be created for 3rd party apps. This means that any package on WinGet can be a "real package" if MSIX version is added. What remains is to automatically generate and host the MSIX packages somewhere, which I'm sure Microsoft is planning to do.

Microsoft: This is literally impossible.
Scoop / Chocolatey / AppGet: We've been doing this for 3 years....

Man this company is such a joke, without even the courtesy of a punchline.

Microsoft: This is literally impossible.
Scoop / Chocolatey / AppGet: We've been doing this for 3 years....

Man this company is such a joke, without even the courtesy of a punchline.

Let's try and keep this issue productive

I've had some time to think about the issue as as a broad, universal issue, not specific to winget, and learned a bit more since I
last made a suggestion about this,
I think I didn't explain myself that well.
I see now we have a basic uninstall capability similar to what you can do in windows uninstaller and that's great,
now we're basically dealing with more edge cases and backwards compatibility.
Because of course the reason why other some package managers work so well is they are built from the ground up for
a specific package format and everybody builds packages for them from the get go, chocolatey and scoop does this to a
lesser degree but this isn't really efficient time wise considering the sheer number of apps to deal with,
so we need comparability with existing apps, we're part of  the way there already.
So how to deal with the problem of cleaning up some of the bulkier files that the uninstaller doesn't deal with,
there's kind of 2 solutions as a broad overview, these are both different versions of the same concept.
One of the basic and simplest way to deal with package is just keep a list of files and install these files and remove them
again before managing the package, removing or updating, or in some cases writing over the top.
In many cases this "list" is actually a file archive that just drops everything from the archive into the filesystem without much
care for the outcome, as long as the package manager checks for existing file conflicts or resolves them with something like an
atomic Nix store.
This works fine but there is 1 major flaw.
It's immutable, and file that is added or removed between the installer and the uninstaller, and isn't explicitly picker up by the
uninstall process is left behind, cruft.
My proposed solution that could be worked on, that I didn't explain well was basically intercepting files being written by a
process so they can be tracked, and eventually removed.
Now this has all manners of problems, like extra executable that can't reasonably be monitored, having to actively monitor
a process for writes or intercepting such calls at the Windows kernel level, maybe outside the scope of this project?
Somebody let me know.
Another problem is the files being removed that are necessary for other installed packages for whatever reason, edge cases,
this could be improved with kind of atomic actions that doesn't remove things completely from the system immediately and
the user or the package manager could determine how much of a good idea that way but that's a lot of extra work.
Basic idea is good in my opinion, what I meant by the sandbox is either creating a sandbox, or some similar process that forces
processes from binaries that reside within the package to write within a specific, clean, directory where changes can be listed
and tracked for the uninstall process, the only thing to be mindful with the above solutions is not deleting personal files
immediately.
This system could be extended to create a "package" when you install said "arbitrary executable" from the internet,
simplifies the removal process and helps let the user know where to find files or whatever other information the user ones.
As I mentioned before no other package manager has really solved this problem before, that I know of,
and I think it would be quite unique and an achievement to solve a problem like this.
Hope that makes sense.

@Mallchad Your proposal sounds very similar to what MSIX already is/does: https://docs.microsoft.com/en-us/windows/msix/packaging-tool/create-app-package
Also,

chocolatey and scoop does this to a lesser degree but this isn't really efficient time wise considering the sheer number of apps to deal with

Scoop is the smaller of the two, with only a few hobbyists backing it, and furthermore it has a much more restrictive "package format" than the other ones, sometimes requiring custom PowerShell scripts for manifests to work properly. Despite that, it rarely disappoints me when searching for packages. If a hobby open-source project can manage, Microsoft can manage.
I believe that the root of this issue is actually Microsoft needing to decide the correct direction for winget to go. And I hope that they get the direction right.

I actually wasn't aware this existed and this is what MSIX does...
If it works how I think then half the work is already done right?
If it fairly quickly creates a package from an installer then you could
just provide a helper script accessible through
the CLI utility can create and install packages from a url right? That
wouldn't be too much of an ask or work.
Then you could look into other problems like tracking cruft.
I hope they get the directory right, some of the recent projects have had a
very topsy turvy development and direction and
for the first time in a while I think winget and WSL is a very strong foot
forward, even if it doesn't live up to expectations,
it just needs to work.
I''ve got some stuff to tie up but I'll look into experimenting with MSIX
and winget at some point.
On Sat, 6 Mar 2021 at 11:25, Jan Pokorný notifications@github.com wrote:

@Mallchad https://github.com/Mallchad Your proposal sounds very similar
to what MSIX already is/does:
https://docs.microsoft.com/en-us/windows/msix/packaging-tool/create-app-package
Also,
chocolatey and scoop does this to a lesser degree but this isn't really
efficient time wise considering the sheer number of apps to deal with
Scoop is the smaller of the two, with only a few hobbyists backing it, and
furthermore it has a much more restrictive "package format" than the other
ones, sometimes requiring custom PowerShell scripts for manifests to work
properly. Despite that, it rarely disappoints me when searching for
packages. If a hobby open-source project can manage, Microsoft can manage.
I believe that the root of this issue is actually Microsoft needing to
decide the correct direction for winget to go. And I hope that they get the
direction right.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/winget-cli/issues/121#issuecomment-791918389,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK5GWWLBWIBOCYDB4FXLUU3TCIGJBANCNFSM4M6IISMQ
.

My proposed solution that could be worked on, that I didn't explain well was basically intercepting files being written by a
process so they can be tracked, and eventually removed.
Now this has all manners of problems, like extra executable that can't reasonably be monitored, having to actively monitor
a process for writes or intercepting such calls at the Windows kernel level, maybe outside the scope of this project?

Another problem with this is editor style apps that should leave files behind, or when an app requires uninstallation to update and should keep config files, etc. Additionally this kind of tracking could pose a problem with certain filesystems. The number of issues that could conceivably arise (plus the overhead) would lead me to say that this solution might not be the best. I like a lot of the other ideas you present here though, definitley soemthing to explore.

My proposed solution that could be worked on, that I didn't explain well was basically intercepting files being written by a
process so they can be tracked, and eventually removed.

Yeah if the development community switched fully to msix a lot of (un)install problems could be alleviated. Unfortunately there are a few more steps to MSIX than with either MSI (Wix toolkit) and EXE (inno). Plus I think EXE has a bit more capability. Of course the primary barrier to MSIX for smaller software is still the difficulty of acquiring a code signing certificate.

Hm, a lot of stuff to consider with getting adoption of compatible formats
like MSIX,
probably adoption is the most important thing for this project, getting a
code signing certificate is....
I don't think that will fly as a blanket solution, but many other projects
support user curated packages in one way or another, just I'm just
wondering if MSIX can, or could still be used on a trust basis...
Need to find out more before I can comment much more on that front.
Didn't consider things like editor style apps, that is a problem...
I guess, the least bad solution off the top of my head is to simply track
the changes and leave it up to user descrecian what to remove.
For consistent, easy to work with and package apps I would guess that 99%
of the cruft could be manually compiled into a list of stuff to remove, and
stuff to leave.
I was considering the overhead for such a thing like tracking writes, I was
thinking about how it could be done say, if I add functionality to
facilitate to the Linux kernel,
if we had that level of access I don't see why there would be much
overhead, you just need add some implementation to the filesystem call and
take note of who made the call, assuming such a thing
is recorded somewhere. That's kind of a, let's ask Microsoft and see what
happens thing though, I think... Not aware of the all of the APIs available.
Doing that is userspace is a lot harder, unless you have access to the
location, which is why I thought some kind of lightweight sandboxes is a
hacky alternative.
Need to do more research on this before I say any more.
On Sat, 6 Mar 2021 at 17:30, Tajetaje notifications@github.com wrote:

My proposed solution that could be worked on, that I didn't explain well
was basically intercepting files being written by a
process so they can be tracked, and eventually removed.
Now this has all manners of problems, like extra executable that can't
reasonably be monitored, having to actively monitor
a process for writes or intercepting such calls at the Windows kernel
level, maybe outside the scope of this project?
Another problem with this is editor style apps that should leave files
behind, or when an app requires uninstallation to update and should keep
config files, etc. Additionally this kind of tracking could pose a problem
with certain filesystems. The number of issues that could conceivably arise
(plus the overhead) would lead me to say that this solution might not be
the best. I like a lot of the other ideas you present here though,
definitely something to explore.
My proposed solution that could be worked on, that I didn't explain well
was basically intercepting files being written by a
process so they can be tracked, and eventually removed.
Yeah if the development community switched fully to msix a lot of
(un)install problems could be alleviated. Unfortunately there are a few
more steps to MSIX than with either MSI (Wix toolkit) and EXE (inno). Plus
I think EXE has a bit more capability. Of course the primary barrier to
MSIX for smaller software is still the difficulty of acquiring a code
signing certificate.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/winget-cli/issues/121#issuecomment-791994831,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK5GWWNG6AZ2BJ3EGOABGD3TCJRDDANCNFSM4M6IISMQ
.

Building an MSIX does have it's barriers and limitations. It does, however, provide some of the best end user behavior/experience in terms of silent install and uninstall (as well as the fact that in general they clean up better and help to avoid "win rot"). Take a look at the Azure Code Signing service for some investments being made to make code signing easier.

@dandelon I would love to see a repository of MSIX packages built from 3rd party apps. Similarly to what Scoop does -- have a declarative definition of where to download the software, how to check for the latest version, how to unpack the installer, what shortcuts to create etc. --- but instead of performing the steps client-side, they are executed in a CI/CD pipeline and the result is a MSIX package ready to download and install. Would this be doable, at least for open-source apps (since the license may prohibit this)?

@JanPokorny it would be possible to create a third party source (as soon as the REST implementation is complete) that has MSIX packages exclusively.
We've also been discussing a way to filter by installer type. A few customers have suggested filtering by MSIX.
There are certainly some examples of how to convert or build MSIX installers so it could be possible to build a pipeline that takes packages and wraps them up in an MSIX. Your concerns about distribution are valid. It seems that a best practice could be to reach out to those open source projects that one cares about and help them to build MSIX output in their CI/CD pipelines targeting distribution via MSIX.

@danelon Thanks for the reply. I was thinking that building a repository of MSIX installers would be a great way to address winget's missing features regarding uninstallation/updating. However, I suppose this won't be possible without a way of packaging 3rd party apps to gain traction for the project -- even for established package managers like Chocolatey, there are very few software developers who actually manage the package themselves.

It seems like you are discussing my third proposed solution from #407 - provide automatic MSIX re-packaging workflows for all repository submissions in EXE format.
I stand by my points and suggestions from #407. Please make this an actual package manager with true packages and true, reliable uninstalls. As you have discussed here, custom install/uninstall PowerShell wrappers are:

A lot of ongoing work/maintenance burden
Not provably correct (may miss things or fail)
Already done by Chocolatey

The problem is that there’s tons of popular software that isn’t happy being inside a MSIX, like Steam, or Visual Studio. Apps that need (for whatever reason) to be able to spew files/dependencies all over the system, or have lots of installer options aren’t yet a good fit. I don’t doubt that developers should spend some time thinking about this issue (please! MSI has existed since 1999 and it acts right most of the time), but the entire reason exe support exists at all is because migrating to MSIX is a non-trivial operation for a ton of apps.
(Of course, I’d argue half the reason for it being non-trivial is the signature requirements making distributing repackaged apps difficult, but that’s just my perspective from messing around with it outside of a team building a Windows app.)

The problem is that there’s tons of popular software that isn’t happy being inside a MSIX, like Steam, or Visual Studio. Apps that need (for whatever reason) to be able to spew files/dependencies all over the system, or have lots of installer options aren’t yet a good fit. I don’t doubt that developers should spend some time thinking about this issue (please! MSI has existed since 1999 and it acts right most of the time), but the entire reason exe support exists at all is because migrating to MSIX is a non-trivial operation for a ton of apps.
(Of course, I’d argue half the reason for it being non-trivial is the signature requirements making distributing repackaged apps difficult, but that’s just my perspective from messing around with it outside of a team building a Windows app.)

While I absolutely agree with every single thing you just said (hence my 👍), there is the point to be made about silent installations not working with most EXEs. But honestly if I were the winget team I would just go ahead and allow EXEs but throw a warning when they are installed/added to the repository and disable silent installs￼￼￼ and throw an error when someone tries them. If the problem can be addressed, then it can be addressed down the road, for now EXE support should absolutely be included with winget.￼

Most every EXE currently in the repo is capable of silent installs (there's a couple outliers where the developer broke silent installs in an update, and there's a discussion about interactive-only installs in microsoft/winget-pkgs that I've been meaning to write something on), so I don't think that's a good solution either.
I think the only possible solution is to keep extending MSIX until it can deal with apps that are as complex as Visual Studio/SQL Server/[insert complex app]. If there's a hundred edge cases, no developer will want to deal with it, and since Microsoft doesn't seem to want third-parties repackaging (that makes things like copyright hard, whereas winget just pulling installers the same way a browser does doesn't), I don't know how else to get widespread adoption. Blocking exe files will just mean winget is missing 50% (if not more) of the Windows software catalog, it won't make devs prioritize modern installers.

I must ask, if you insist on EXE support, why don't you just use chocolatey?
Chocolatey has tried very hard, and put a ton of scaffolding in place to try its best to wrangle EXE setups into submission, and to make them behave package-like with wrapper scripts and lots of work that has to be done by the package maintainers.
It would be silly to duplicate all this effort in winget to me.
I know MSIX cannot be used by every application yet. That's why the traditional MSI still exists as well. MSI can handle every type of application so there's no technical limitation - just laziness from some companies who do not want to publish MSI installers.
In my opinion, winget trying to support EXEs like packages (which they ARE NOT) will just mean we:

Duplicate all the work chocolatey maintainers did / still do
Take away a reason for app developers to finally release MSI or MSIX packages (if EXE is "supported" by winget why would they bother changing to MSI/X?)
Will continually run into issues with EXE installers not being removed properly, stealing focus, showing error windows, leaving behind services etc. etc.

I understand some of you just want to type winget install <shittySoftware> and have it done, but if you really feel like you must install Steam this way then just use chocolatey. winget needs a differentiating factor anyway, it's the new tool on the block and the underdog - what is its differentiating factor? Well, imo, it should be that chocolatey is just a glorified EXE runner and winget could be an ACTUAL package manager - less software selection, sure, but only real and honest packages with perfect silent installs and removals and perfect ability to keep track of versions and dependencies. None of that will ever be possible with EXEs.
I don't see any value in recreating chocolatey, which already exists if you want it.
winget should be different, and better in some ways. Let's make it better by only supporting MSI and MSIX. Since this is an official Microsoft tool that will even ship included in Windows, this will (once it ships in Non-Insider builds) further promote the use of MSI and MSIX and the software selection will improve naturally as people start using winget and request more and more packages/software be released as MSI/X - and if you feel like you cannot wait for that then just use chocolatey today.
Not trying to argue, this is really quite cut and dry to me. I only see downsides and problems with supporting EXE and absolutely no benefit. Especially think about the point that supporting EXEs is not only bad, it also means there is absolutely no incentive for companies and developers to adopt/switch to MSI or MSIX which hurts the entire Windows platform in the long run, that is really quite a severe and long-term problem!

Chocolatey executes arbitrary PowerShell scripts and wants admin rights as opposed to winget only allowing a manifest to pass specific command-line flags, that's enough for me to not want to use it.

Take away a reason for app developers to finally release MSI or MSIX packages (if EXE is "supported" by winget why would they bother changing to MSI/X?)

I don't think a CLI package manager, even if Microsoft backed, will convince companies to invest in decent installer infrastructure where 20+ years of SCCM and it's brethren couldn't (not to mention GPO software installs, Chocolatey, NuGet, PDQ Deploy...). It's clear they need a turnkey-ish solution to be interested (or for Microsoft to say that arbitrary exes will no longer be allowed to write outside of user directories, but the chances of that happening are slim to none).
It's unfortunate, it really is, but for adoption, you either need to support EXEs and all of their warts, or begin a mass effort from Microsoft to the software vendors to plead them to either adopt MSIX or explain why they can't so it can be improved. I
(Or, I suppose, Microsoft could allow the community to send in build scripts for turning EXEs into MSIXs in winget manifests, and they could repackage and sign, and then host those files for the users so when they run winget install they receive the repackaged MSIX. As I mentioned before though, I think they may run afoul of some copyright stuff with this. It would allow us to crowdsource what applications can't currently be packaged as MSIXs though, which could be useful).

I must ask, if you insist on EXE support, why don't you just use chocolatey?
Chocolatey has tried very hard, and put a ton of scaffolding in place to try its best to wrangle EXE setups into submission, and to make them behave package-like with wrapper scripts and lots of work that has to be done by the package maintainers.
It would be silly to duplicate all this effort in winget to me.
I know MSIX cannot be used by every application yet. That's why the traditional MSI still exists as well. MSI can handle every type of application so there's no technical limitation - just laziness from some companies who do not want to publish MSI installers.
In my opinion, winget trying to support EXEs like packages (which they ARE NOT) will just mean we:

Duplicate all the work chocolatey maintainers did / still do

Take away a reason for app developers to finally release MSI or MSIX packages (if EXE is "supported" by winget why would they bother changing to MSI/X?)

Will continually run into issues with EXE installers not being removed properly, stealing focus, showing error windows, leaving behind services etc. etc.

I understand some of you just want to type winget install <favoriteSoftware> and have it done without thinking about it, but if you really feel like you must install Steam this way then just use chocolatey. winget needs a differentiating factor anyway, it's the new tool on the block and the underdog - what is its differentiating factor? Well, imo, it should be that chocolatey is just a glorified EXE runner and winget could be an ACTUAL package manager - less software selection, sure, but only real and honest packages with perfect silent installs and removals and perfect ability to keep track of versions and dependencies. None of that will ever be possible with EXEs.
I don't see any value in recreating chocolatey, which already exists if you want it.
winget should be different, and better in some ways. Let's make it better by only supporting MSI and MSIX. Since this is an official Microsoft tool that will even ship included in Windows, this will (once it ships in Non-Insider builds) further promote the use of MSI and MSIX and the software selection will improve naturally as people start using winget and request more and more packages/software be released as MSI/X - and if you feel like you cannot wait for that then just use chocolatey today.
Not trying to argue, this is really quite cut and dry to me. I only see downsides and problems with supporting EXE and absolutely no benefit. Especially think about the point that supporting EXEs is not only bad, it also means there is absolutely no incentive for companies and developers to adopt/switch to MSI or MSIX which hurts the entire Windows platform in the long run, that would really be quite a severe and long-term consequence!
We either fix windows software installs with winget together, today, or we stay in the dark ages of shoddy, problematic software handling on Windows until Microsoft eventually tries again in 25 years with winget2, or msget or whatever they'll call it. Why would we consciously choose that?

You make some good points here but "why not use Chocolatey" is like responding to a bug in notepad by saying why not use Sublime Text? Because if Microsoft is gonna release a product it should be a good and well rounded one.

Chocolatey executes arbitrary PowerShell scripts

Which it doesn't do because it wants to. It does it this way because it needs the custom scripts to work around the problems of the EXE installers it supports.

and wants admin rights

winget needs admin rights too to install software machine-wide, especially EXEs. Funnily enough, there is actually an option in Windows to allow a non-admin to install MSI-packages machine-wide without administrator rights, but with EXEs this is not possible at all and winget cannot work around this unles they want to run a permanently elevated background service (which it currently does not do, which is why it UAC prompts you to run software installers) - yet another disadvantage of EXEs

as opposed to winget only allowing a manifest to pass specific command-line flags, that's enough for me to not want to use it.

That is cool, but not enough to support EXEs. Notice how winget can get by with just a manifest today, but it is in very early alpha and its features and exact scope are still heavily discussed. Also note how chocolatey has been out for many many years and has a somewhat well-defined goal and approach, and wide software support - and it uses PowerShell wrapper scripts. That's not a coincidence. In order to support all the problematic EXE installers out there, you need a lot of flexibility and possible options and capabilities in your installation process (create files, remove files, create registry keys, delete registry keys, check for pending reboots, set environment variables etc. etc.) and that means you either go the chocolatey route and give package maintainers full cretive freedom with custom PowerShell scripts, or you completely blow the manifest spec out of proportion by supporting every possible thing an EXE might need or want done prior and after its execution to run as expected, and cleanly aka without residual files or registry entries.
Which problem do you choose?
I say neither. I don't want arbitrary PowerShell scripts run as admin on my system and I don't want an overblown, overcomplicated manifest format that will need to be supported, maintained, backwards-compatible and bug-tested for every niche scenario by the poor winget developers.
Instead, imagine if we just use MSI and MSIX. No PowerShell scripts needed. Manifest format could be dead-simple and still work/support all packages. All software could be installed with or without admin-rights, guaranteed. No special snowflakes, no surprises.
I know not all EXE installers are equally bad. Some of them are almost as good as MSI packages, sure. But because you cannot know that just by inspecting the setup file from the outside, winget knows nothing when it runs the EXE - aside from what the manifest theoretically promises. But what about EXE setups that bundle a dependency like Microsoft Visual C++ Redist 2017 - how do you teach winget about the fact that installing this will also install another software? How would you subsequently uninstall or update that dependency-software with winget? The only way is through the manifest, make the manifest more complicated to indicate bundled dependencies and their full package specifications. Then the software auto-updates itself and winget cannot know that if it's an EXE because there's no central database of version numbers for installed EXE software, unlike MSIs. When an MSI software is updated outside of winget, winget notices that and can correctly show it as up-to-date. How do you fix this for EXEs? In the manifest? You can't. You could only fix it by disallowing EXE installers.
See, chocolatey uses PowerShell scripts and their flexibility for a reason. That reason is, they chose to go the route of allowing EXE installers - and now you yourself say, ugh, that's messy and I don't want it. But winget is headed for the same fate.

You have some good points, and I'd be convinced if I could see a path to getting software vendors on board....

Then the software auto-updates itself and winget cannot know that if it's an EXE because there's no central database of version numbers for installed EXE software, unlike MSIs. When an MSI software is updated outside of winget, winget notices that and can correctly show it as up-to-date. How do you fix this for EXEs? In the manifest? You can't. You could only fix it by disallowing EXE installers.

Add/Remove Programs functions as this for EXE installers, and winget will eventually have support for adding standalone (non-installer) apps to it. Whether that encourages lazy app development is up to the reader.

The only problem, and I mean the only problme, I see with ignoring excutables, is adoption...
It would be quite difficult to get developres to adopt the package manager for a while...
And until then Winget has greatly diminsihed usage/use-case, like it does now.
Although I get there is a lot of problems with supporting "legacy" installers and it might be a waste of effort in areas.
With this in mind if Winget were to support "legacy" installers, I think the lowest effort (but still effective) solution should be found.
Backwards compatability as I'm sure you know is an ongoing problem.
Unless somebody were to propse integration / chocolatey support.

Interesting discussion around the pains of MSI: https://news.ycombinator.com/item?id=26846696

@jedieaston Microsoft is now in a great position to make MSIX better (drop signature requirement, add direct support to common setup wizard frameworks to make adoption easier, ...) and push it using winget ("you can put your app on winget, just use this installation format your pipeline probably already supports"). Once winget is included in Windows, developers might even use it to auto-update their apps basically for free. I don't think there's a high chance of this happening, but it would surely be great.

@jedieaston Microsoft is now in a great position to make MSIX better (drop signature requirement, add direct support to common setup wizard frameworks to make adoption easier, ...) and push it using winget ("you can put your app on winget, just use this installation format your pipeline probably already supports"). Once winget is included in Windows, developers might even use it to auto-update their apps basically for free. I don't think there's a high chance of this happening, but it would surely be great.

The MSIX format is really horrendous because it allows the insertion of DRM in software through the form of the AppxBlockMap.xml files.
On top of that, it is only supported on windows.
It is really the most horrible and frustrating one of the choices.
Really really awful that microsoft is attempting to push forward with the locking of windows, without fixing any of the underlying problems of the platform.

@keenbowl3009 Most paid software already has DRM, with or without MSIX.
Also, how is "it is only supported on Windows" an argument? Scoop is only supported on Windows, Homebrew is only supported on Mac and Apt is only supported on Linux, does that make them bad?

scoop is a shell script that unzip files, and adds to path.
can you unzip files, and add them to path with winget?

https://devblogs.microsoft.com/commandline/windows-package-manager-preview/

You are going to be able to winget install your way to bliss. One of the best parts is that it is open source. I had to pinch myself when I was able to winget install terminal, and then winget install powershell, and then winget install powertoys.

Can you winget install any of those from the original winget annoucement?

scoop is a shell script that unzip files, and adds to path.
can you unzip files, and add them to path with winget?

No, it's on the roadmap, and I don't get how it's related to the previous conversation.

Can you winget install any of those from the original winget annoucement?

All of them? In fact I installed all of these through winget. What are you even trying to say?

Given that

A. You don't like winget
B. You like scoop

I suggest that you

Use scoop

Yet another bad faith argument, seems people love these lately

@tajetaje Since this issue is closed, I don't see much value in marking the thread "off topic". Unfortunately, there probably isn't a single solution that will make everybody happy. Sometimes people want to make sure they are heard. There are several tools attempting to solve the problems related to managing software on Windows. We're not trying to replace any of them. We're trying to meet developers where they are and have a plan to go forward in time. Some of the constraints we're trying to adhere to make the problems more challenging in some areas and easier in others. Hopefully over time, we will build something that is flexible enough to give the control users want and the flexibility to work with existing installers.

scoop is a shell script that unzip files, and adds to path.
can you unzip files, and add them to path with winget?

No, it's on the roadmap, and I don't get how it's related to the previous conversation.

Can you winget install any of those from the original winget annoucement?

All of them! In fact I installed all of these through winget. What are you even trying to say?

winget install powershell will literally give me an error.
On top of that, i'm afraid of even running that and permanently borking my machine.

If you are getting a error installing something, open a ticket. Things can't get fixed if the devs don't know of the issue

@denelon > We're not trying to replace any of them.
I'd be... more cautious with that statement. https://keivan.io/the-day-appget-died/

https://github.com/microsoft/winget-cli/issues/353#issuecomment-637016016
Last I'll say on the topic

@keenbowl3009 If you're afraid, don't use winget. Nobody is forcing you. If you want to install PowerShell manually, feel free to go to https://github.com/PowerShell/PowerShell/releases/download/v7.2.0/PowerShell-7.2.0-win-x64.msi and run it yourself, although be aware that you will be doing precisely the same thing as the winget you're afraid of.
Also there is no error, unless you mean the disambiguation note which happens if you enabled the msstore source and thus have two locations to install PowerShell from.

@tajetaje Yeah, I know. I just felt the itch to point this out, due to the statement's wording reminding me of this controversy. (Also did the "something to share" already happen?)

Also there is no error, unless you mean the disambiguation note which happens if you enabled the msstore source and thus have two locations to install PowerShell from.

There is no error.
Unless, of course, there's an error.
Then the error is a feature!

@keenbowl3009 If you're afraid, don't use winget. Nobody is forcing you. If you want to install PowerShell manually, feel free to go to https://github.com/PowerShell/PowerShell/releases/download/v7.2.0/PowerShell-7.2.0-win-x64.msi and run it yourself, although be aware that you will be doing precisely the same thing as the winget you're afraid of.
Also there is no error, unless you mean the disambiguation note which happens if you enabled the msstore source and thus have two locations to install PowerShell from.

I have not "enabled" mstore.
It get's enabled by itself, automatically.
Absolutely no input on my side.

If you are getting a error installing something, open a ticket. Things can't get fixed if the devs don't know of the issue

Thanks.
https://github.com/microsoft/winget-cli/issues/1711

@keenbowl3009 Using command line package managers requires a basic degree of computer literacy, including the ability to comprehend bright yellow text in simple English. I am afraid that I can not help you further, sorry.

If you already had a ticket, what was the point other than to scratch the chip on your shoulder you seem to have of bringing it up.
I'm done. Its obvious you arent acting in good faith and just want to stir up trouble

IMHO it is a dishonest attitude closing this issue since the uninstaller is currently broken and most of the time does not work.

@EqualDust The feature is implemented, that's why this issue is closed. It can certainly be buggy for some uninstallers -- the correct attitude to fix this problem is to report each individual bugged uninstaller.
Also, stop creating new GitHub accounts, please.

every bug is a new account. Reporting each individual bugged uninstaller is inneficient, an org with resources like msft should be able to ship great products by default.
How come scoop, completely community backed, get this right by default?
On Mon, Nov 29, 2021, at 12:13 PM, Jan Pokorný wrote:

@EqualDust https://github.com/EqualDust The feature is implemented, that's why this issue is closed. It can certainly be buggy for some uninstallers -- the correct attitude to fix this problem is to report each individual bugged uninstaller.
Also, stop creating new GitHub accounts, please.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/microsoft/winget-cli/issues/121#issuecomment-981727856, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWWRYBNXOGOLZREBW23XJG3UOOJ7ZANCNFSM4M6IISMQ.
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Please don't make an ordeal of this,
the topic of the issue has been resolved, if you have an issue (and I don't doubt you have),
it is correct to make a new issue.
This thread is getting long and very noisy now, noisy threads are hard to follow.

authors: BrainSlugs83 Caltor DiegoMagdaleno EqualDust JanPokorny Karl-WE KevinLaMS Mallchad Masamune3210 Smart123s denelon jantari jedieaston keenbowl3009 masx200 michaelvolz phiresky sredna tajetaje zQueal

repo: microsoft/winget-cli


text:
What type of update are you requesting?
A new version of an existing package
Current Package Identifier
DG0JBJ.HDSDR
Package Version
2.81-b10
Please describe the changes you would like to see
There is a new release (2.81-b10) available. Download Page Url: https://www.hdsdr.de (https://www.hdsdr.de/download/HDSDR281b10_install.exe)

Also feel free to add the previous 2.81-b9:
https://www.hdsdr.de/download/HDSDR281b9_install.exe

source: gharchive/issue

repo: microsoft/winget-pkgs

license: MIT

license_type: permissive

license_source: github-api


text:
Neovide.Neovide version 0.10.4

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

This package is expecting arguments. Using -help gives:
Neovide: No Nonsense Neovim Gui

Usage: neovide.exe [OPTIONS] [FILES_TO_OPEN]... [-- [NEOVIM_ARGS]...]

Arguments:
  [FILES_TO_OPEN]...  Files to open (plainly appended to NeoVim args)
  [NEOVIM_ARGS]...    Arguments to pass down to NeoVim without interpreting them

Options:
      --geometry <GEOMETRY>
          The geometry of the window [default: 100x50]
...

source: gharchive/pull-request

authors: sarvex stephengillie


text:
TeamZedbyte.testdashdrop version 0.0.1

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?
[x] Have you tested your manifest locally with winget install --manifest <path>?
[x] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Close with reason: Stale pull request;


text:
New version: YuzuEmu.Yuzu.Mainline version 1680

Pull request has been created with Komac v1.11.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

For moderators
This account is automated by Github Actions and the source code was created by CoolPlayLin. If you have any questions about any pull request, don't hesitate to ping @Exorcism0666, I'll get a notification.

[!important]
Please carefully review these Pull Request before merging. If it is a Pull Request for removing incorrect content and the URLs are issue, free upon manual checking, please close this Pull Request directly. (It is best to inform Exorcism0666 of the closure.)

良い一日をお過ごしください！


text:
SpikeHD.Dorion version 4.1.0

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?
[x] Have you tested your manifest locally with winget install --manifest <path>?
[x] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Hi @headquarter8302,
This manifest adds Apps and Features entries that aren't present in previous PR versions. Should these entries also be added to the previous versions?
(Automated response - build 567.)


text:
New version: Reqable.Reqable version 2.6.1

This pull request is automatically generated by 🥟 Dumplings in #3268
Microsoft Reviewers: Open in CodeFlow

/AzurePipelines run

authors: SpecterShell stephengillie


text:
Modify: Amazon.Corretto.21 version 21.0.0.35

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Hi @SpecterShell,

This PR's version number 21.0.0.35 has 4 parameters (sets of numbers between dots - major, minor, etc), which is less than the current manifest's version 21.0.0.35.1, which has 5 parameters.

Does this PR's version number exactly match the version reported in the Apps & features Settings page? (Feel free to attach a screenshot.)
(Automated response - build 880)


text:
New version: Project64.Project64.Dev (version 4.0.0.6429)

Checklist for Pull Requests

[Y] Have you signed the Contributor License Agreement?
[N] Is there a linked Issue?

Manifests

[Y] Have you checked that there aren't other open pull requests for the same manifest update/change?
[Y] This PR only modifies one (1) manifest
[Y] Have you validated your manifest locally with winget validate --manifest <path>?
[Y] Have you tested your manifest locally with winget install --manifest <path>?
[Y] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Hello @seangibbz,
One or more of the installer URLs doesn't appear valid.
This may happen for sites with policies prohibiting distribution or use by third parties.
This may happen for URLs pointing to domains that do not align with the publisher domain or package domain. If you could provide supporting evidence from the publisher that the URLs for the installer are correct, that would help us to validate and approve this PR.
Template: msftbot/validationError/urls/domain

The installer URL is correct, as if provided on the official downloads page.
This URL downloads the appropriate installer when used with winget.

https://github.com/microsoft/winget-pkgs/issues/142854

authors: seangibbz stephengillie


text:
Remove version: Tableau.Reader version 24.1.827

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

For moderators or/and anyone else

[!Caution]
As a result of several personal problems I've had over the last few months + my final exams coming up very soon, I'm currently unable to look at my GitHub notifications every day and maintain my executions correctly.
If you detect a certain problem on a certain pul request:

Either you can close the pull request directly without mentioning me.
Or you can send me a message on X (Twitter): @Exorcism0666

Thank you for your understanding, and I'm sorry if some pull requests can't be approved due to the situation I'm in.

This account is automated by Github Actions and the source code was created by CoolPlayLin. If you have any questions about any pull request, don't hesitate to ping Exorcism0666.

[!warning]
With the new version of Komac, numerous Pull Requests may contain bugs or unwanted elements. If such issues arise, please tag russellbanks so that these bugs can be addressed in future updates.

[!important]
Please carefully review these Pull Request before merging. If it is a Pull Request for removing incorrect content and the URLs are issue, free upon manual checking, please close this Pull Request directly. (It is best to inform Exorcism0666 of the closure.)

良い一日をお過ごしください！

URL: https://downloads.tableau.com/tssoftware/TableauReader-64bit-2024-1-1.exe
Response Error: The remote server returned an error: (403) Forbidden.
(Automated message - build 912)


text:
Remove version: Jackett.Jackett version 0.21.2175

404 - release deleted
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/Jackett/Jackett/releases/download/v0.21.2175/Jackett.Installer.Windows.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 918)

authors: russellbanks stephengillie


text:
Add Microsoft/WindowsSDK-10.0.19041.1.

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] Have you validated your manifest locally with winget validate <manifest>, where <manifest> is the name of the manifest you're submitting?
[x] Have you tested your manifest locally with winget install -m <manifest>?

Microsoft Reviewers: Open in CodeFlow

This is a duplicate.  The final build was a version 10.0.19041.1 but the version VS shows is the 10.0.19041.0.

You are right. I'm only checking the version number of the installer not the link itself. I will check the links too. Thanks for the warning! 🥂

authors: KevinLaMS yigitemres


text:
New Package: Microsoft.NuGet

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.1 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Beep boop


text:
Differentiate between setup and cleanup requests and requests for the actual test

This would help people better understand what tests are doing.

We are in the process of closing this GitHub repository.  This issue has been moved to the CSPP team ADO backlog list for consideration.

authors: tylerbutler v-stefansi

repo: microsoft/wopi-validator-core


text:
xmag doesn't work

Environment
Your Distribution version: Ubuntu
Your WSLG version: 0.2.9
Steps to reproduce
run xmag
Note:
Same issue repro with Ubuntu in Wayland mode. Ubuntu in X11 mode works fine. Given our WSLg is always work in Wayland mode. This has to be fixed in Wayland globally.

I think that xmag can not be fixed in this setup. It relies on X11 functionality (ability to get any pixel value on the screen, even outside its own window) that Wayland does not support by design, since they consider it a security risk.
And since WSLg is Wayland based, it can not be fixed.
xmag would have to be re-written to support some Wayland protocol, but then it would no longer be an X11 program.
For the same reason, all X11 based screenshot, screen recording software, color picker functionality in color selection dialogs... will also not work.

repo: microsoft/wslg


text:
Confusion with @microsoft/microsoft-graph-client

Your NPM page is https://www.npmjs.com/package/@microsoft/msgraph-sdk-JAVASCRIPT
Your github page URL is https://github.com/microsoftgraph/msgraph-sdk-TYPESCRIPT
Your github repo name is microsoftgraph/msgraph-sdk-TYPESCRIPT.
And your documentation about setting up an Authentication provider points to this Microsoft docs page which references a completely different package, for which the:
NPM page is https://www.npmjs.com/package/@microsoft/microsoft-graph-client
Github page is https://github.com/microsoftgraph/msgraph-sdk-JAVASCRIPT
Github repo is microsoftgraph/msgraph-sdk-JAVASCRIPT
Im trying use to your app with our msal.ConfidentialClientApplication but with no luck, the authProviders have different types (callback for @microsoft/microsoft-graph-client and class for your app)
I hope you can see why I am confused 😅

Hi @tboulis
Thanks for trying this SDK and for reaching out.
We're still in very early preview days, and trying to figure out the best approach here.
So far, here are our plans.

package name
repo name
notes

@microsoft/microsoft-graph-client
microsoftgraph/msgraph-sdk-javascript
the historical and legacy client, will be replaced over time by this new set of packages, the repository name will be renamed as well to free up the name

@microsoft/msgraph-sdk-javascript
this repo
npm package is deprecated, older attempt at delivering a fluent API

@microsoft/msgraph-sdk-core
microsoftgraph/msgraph-sdk-typescript-core
core functionality shared by the fluent API packages

@microsoft/msgraph-sdk
this repo
base (empty) client, and all the models for the v1 API

@microsoft/msgraph-beta-sdk
microsoftgraph/msgraph-beta-sdk-typescript
base (empty) client, and all the models for the beta API

@microsoft/msgraph-sdk-users (and many others)
this repo
v1 fluent API for all APIs under /users

@microsoft/msgraph-beta-sdk-users (and many others)
microsoftgraph/msgraph-beta-sdk-typescript
beta fluent API for all APIs under /users

The idea currently being:

install @microsoft/msgraph-sdk this will get you the models and the an empty client.
install @microsoft/msgraph-sdk-users (or another one), this will add the fluent API for all operations under /users.
start writing your application

Over time, we'll most likely rename the repositories from microsoft/msgraph-sdk-typescript to microsoft/msgraph-sdk-javascript to reduce confusion, but this will only ever happen when the work here is ready for general availability.
I hope this clarifies the current state of things and future plans.
Let us know if you have questions/feedback.

@baywet Could you please pin this issue or put the table in the repo README? I'm wasting a lot of time figuring out where I am supposed to get the Client object.
When all I want is to call graph API with my user.
  const tokenCredential = identity.getDefaultAzureCredential();

  const options: TokenCredentialAuthenticationProviderOptions = {
    scopes: [
      // '.default',
      "https://graph.microsoft.com/.default",
    ],
    getTokenOptions: {},
  };

  // Create an instance of the TokenCredentialAuthenticationProvider by passing the tokenCredential instance and options to the constructor
  const authProvider = new TokenCredentialAuthenticationProvider(tokenCredential, options);

  const requestAdapter = new FetchRequestAdapter(authProvider); // Type mismatch - likely due to legacy @microsoft/microsoft-graph-client
  const graphClient = Client.initWithMiddleware({ authProvider: authProvider });

  const jane = await graphServiceClient.users.byUserId("jane@contoso.com").get();

the code here imports some Client but what it is. Nobody knows.

@1oglop1 where did you get this client initialization code from? You shouldn't need the Client.InitWith... anymore.
See this documentation
Also, if you want to call beta endpoints, you need to install the beta SDK instead documentation

It is not just about beta endpoints.
I tried to view the documentation, but this is my main beef with Microsoft docs, one page with incomplete examples leads to another page with incomplete examples.
It would be way easier if there were complete executable examples.
Example for this case:
this documentation ( link from )  https://github.com/microsoftgraph/msgraph-sdk-typescript/blob/6c55abb9b6593687899111f92c5f914eb8fd3fe8/README.md?plain=1#L32
Shows incomplete an example and delegates the creation of authProvider to another page
import { FetchRequestAdapter } from "@microsoft/kiota-http-fetchlibrary";
import { createGraphServiceClient } from "@microsoft/msgraph-sdk";
import "@microsoft/msgraph-sdk-users";

const requestAdapter = new FetchRequestAdapter(authProvider);
const graphServiceClient = createGraphServiceClient(requestAdapter);

const jane = await graphServiceClient.users.byUserId("jane@contoso.com").get();

When the user clicks on the link choose a Microsoft Graph authentication provider.
They are redirected to the page with another incomplete example, that contains an incompatible type with this SDK.
// @azure/identity
const credential = new InteractiveBrowserCredential({
  tenantId: 'YOUR_TENANT_ID',
  clientId: 'YOUR_CLIENT_ID',
  redirectUri: 'http://localhost',
});

// @microsoft/microsoft-graph-client/authProviders/azureTokenCredentials
const authProvider = new TokenCredentialAuthenticationProvider(credential, {
  scopes: ['User.Read'],
});

const graphClient = Client.initWithMiddleware({ authProvider: authProvider });

As a complete newcomer to AzureSDKs it took me several hours to put the pieces together to authenticate as "me" just by running az login to get this working.

Working code example (click to unfold)
import * as identity from "@azure/identity";
import * as gc from "@microsoft/microsoft-graph-client";
import {
  TokenCredentialAuthenticationProvider,
  TokenCredentialAuthenticationProviderOptions,
} from "@microsoft/microsoft-graph-client/authProviders/azureTokenCredentials";

(async () => {

  const tokenCredential = identity.getDefaultAzureCredential();

  const options: TokenCredentialAuthenticationProviderOptions = {
    scopes: [
      // '.default',
      "https://graph.microsoft.com/.default",
    ],
    getTokenOptions: {},
  };
  const authProvider = new TokenCredentialAuthenticationProvider(tokenCredential, options);
  const client = gc.Client.initWithMiddleware({
    authProvider: authProvider,
  });

  const subscriptionId = "1234-uuid"; // azure subscription id
  const resourceGroup = "DefaultResourceGroup-WEU";
  const partnerTopic = "msGraphGroups2";
  const location = "westeurope";

  const resp = await client.api('/subscriptions')
  .get();
  console.log(resp);
})();

When I tried using this SDK, I got just as confused as I was at the start because the authProvider type needed by the requestAdapter doesn't match what's in the docs.
Say I overcome the authentication problem, try this (new) SDK. Here's my resolution process:

read the docs for the synchronization https://learn.microsoft.com/en-us/graph/api/synchronization-synchronization-list-jobs?view=graph-rest-1.0&tabs=http
Find the url the client has to execute GET /servicePrincipals/{id}/synchronization/jobs/
find the correct packages msgraph-sdk-*

Now step 3. is also slightly confusing due to API structure. Based on my experience with other SDKs I'd be looking for the SDK  named msgraph-sdk-servicePrincipals, because that's the resource the endpoint starts with.
However, this one does not contain the call to the correct endpoint. And somehow I need to find out that it is the msgraph-sdk-applications I need. - the question is where do I learn this fact if there isn't a complete executable example?
IMO the authors of the docs assumed a higher level of familiarity with Microsoft APIs which is often not the case and I missed several clues which caused me a cognitive overhead.
Minor rants:

The implicit behaviour of import "@microsoft/msgraph-sdk-users"; which injects the code in the main client.
Forcing the sdk user to do null checks where an error would be more appropriate - I have never encountered where get_by_id would return undefined instead of HTTP (404) error.

  const requestAdapter = new FetchRequestAdapter(authProvider); // Type mismatch - likely due to legacy @microsoft/microsoft-graph-client
  const graphClient = createGraphServiceClient(requestAdapter);
  const appRequest = graphClient.applications.byApplicationId("");
  const result = await appRequest.get()  // why is this undefined instead of error?

I hope this write-up shows the missing cognitive links, please let me know if there is anything difficult to understand (English is not my first language). This situation evokes 15 standards (xkcd) feelings and I am a bit frustrated by the inability to do a seemingly simple thing.

Thank you so much for this amazing feedback!
Yes I can see where the confusion comes from here.

the documentation Shows incomplete an example and delegates the creation of authProvider to another page

This links points at samples for the old SDK, I think we put the link here assuming the samples would get updated upon general availability, but until then it creates more confusion than anything. @jasonjoh do you think it'd be possible to add a set of "TypeScript (Preview)" tabs on this page and link to that instead from here? (or rename the current TypeScript tab to javascript to be consistent with the rest of the documentation and add a new TypeScript tab)

When I tried using this SDK, I got just as confused as I was at the start because the authProvider

Yes the mix between the two generations of SDKs created more confusion than anything. We changed the approach from the initial previews of this new SDK. And they are now entirely separate products to avoid any further confusion. Sorry the auth docs lead you back to the older SDK.

Say I overcome the authentication problem, try this (new) SDK. Here's my resolution process

Yes the operations docs only have a JavaScript tab at this moment, snippets for this new TypeScript preview SDK is still work to be done. https://github.com/microsoftgraph/microsoft-graph-devx-api/issues/1939

Based on my experience with other SDKs I'd be looking for the SDK named msgraph-sdk-servicePrincipals, because that's the resource the endpoint starts with.
However, this one does not contain the call to the correct endpoint. And somehow I need to find out that it is the msgraph-sdk-applications I need. - the question is where do I learn this fact if there isn't a complete executable example?

I'm not sure I understand why you need applications package for an operation under service principals at this stage?

const appRequest = graphClient.applications.byApplicationId("");
const result = await appRequest.get()  // why is this undefined instead of error?

This is most likely a bug, the SDK should have complained about passing an empty string to begin with. Can you file a separate issue for that please?
Note: the error probably comes from a lack of validation here

I'm concerned that will introduce more confusion by using different SDKs across JS/TS. We've also adopted the policy that our docs will reference GA versions of SDKs only. During preview, it might make sense to remove the link back to our docs using the GA SDK and just put some inline examples of a few of the more common auth providers to help folks get started.

Thanks for your input @jasonjoh
@1oglop1 can you create another additional issue for the readme to remove the link and add the additional snippets here for authentication please?

Thanks for creating the first issue @1oglop1
Can you also create one for that please?

const appRequest = graphClient.applications.byApplicationId("");
const result = await appRequest.get() // why is this undefined instead of error?

This is most likely a bug, the SDK should have complained about passing an empty string to begin with.
Note: the error probably comes from a lack of validation here

Sorry for my late reply, I noticed I did not hit the button 😮💨 🌴

I'm not sure I understand why you need applications package for an operation under service principals at this stage?

Yes, that is exactly my point, I should not need applications package IMO. However, I do not think there is much we can do about it.
The endpoint GET /servicePrincipals/{id}/synchronization/jobs/ is represented as applicatons ->
https://github.com/microsoftgraph/msgraph-sdk-typescript/blob/460cd99af98aaefc3f1a10f0484fc2353bca90b3/packages/msgraph-sdk-applications/applications/item/synchronization/jobs/item/restart/index.ts#L29
But when you look at the REST API documentation it follows the structure from here:
https://learn.microsoft.com/en-us/graph/api/synchronization-synchronizationjob-provisionondemand?view=graph-rest-1.0&tabs=http

This is most likely a bug, the SDK should have complained about passing an empty string to begin with. Can you file a separate issue for that please?
Note: the error probably comes from a lack of validation here

I would not worry about that, I've never executed the code, only type completion so that I can explore the API via using the client instead of searching docs.

@baywet thank you for #628! 🙌
This was the missing link, now I should be able to use the managed identity and this
// @azure/identity
const credential = identity.getDefaultAzureCredential();
// @microsoft/kiota-authentication-azure
const authProvider = new AzureIdentityAuthenticationProvider(credential, ["https://graph.microsoft.com/.default"]);

Thank you for the additional information .
Yes, the table of content for the documentation can be a bit confusing at times as it doesn't map exactly with the structure of the API.
This is outside of the scope of this repository though.
I'm glad that the additional documentation for the authentication providers has helped you solve your issue.
I still think that we need to fix the input validation issue I talked about.
Is this something that you want to follow up on or should I do it on my own?

@baywet
I was confident that the input validation was not a problem so dug deeper into the SDK and created #632.
Let's continue the discussion there.

authors: 1oglop1 baywet jasonjoh tboulis

repo: microsoftgraph/msgraph-sdk-typescript


text:
Pricing Table module not saving header above correct column

I tested the new Pricing Table module with 4 columns and found that if I change a column header title it saves above the wrong column. Also in one test I used the word 'Basic' in all columns, 'Basic1', 'Basic2', 'Basic3', 'Basic4', saved, refreshed, and the first header shows 'Basic4321', all the others show 'Basic'. I repeated the test using 'Test1', 'Test2', etc and it saved ok, so maybe it is because the default template also uses the word 'Basic' in it's header.
When I changed one of the headers from 'Test4' to 'Basic4' the result was 'Test1', 'Test2', 'Test4 3', 'Basic'.
Also this module is using the Parallax icon.

thanks for report we will check it out

Also when setting a button url it sets all button urls to the last saved button url. The following change in file userfiles\modules\pricing_table\templates\default.php seems to fix it, parameter $i added to the button module id:
Line 53:
<module type="btn" button_style="<?php print $buttonColor; ?>" template="bootstrap" id="dbtn_<?php print $params['id'] ; ?>"/>
Change to:
<module type="btn" button_style="<?php print $buttonColor; ?>" template="bootstrap" id="dbtn_<?php print $params['id'] . '-' . $i; ?>"/>

authors: nickwuk peter-mw

repo: microweber/microweber


text:
Release failed to GitHub

Prerequisites

[x] Are you running the latest version?
[x] Did you perform a search to see if this problem was already reported?

For more information, see the CONTRIBUTING guide.
Description
Release to GitHub failed
Environment
Please paste the output of:

go version

% go version
go version go1.9.1 darwin/amd64

uname -a

% uname -a
Darwin midori.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64

goreleaser --debug

% goreleaser --debug -rm-dist
   • running goreleaser 0.35.4
   • loading config file       file=.goreleaser.yml
   • loaded config file        config={ { false false  map[]} { { }     []  []   map[]} [{[windows darwin linux] [amd64] [] []    gtrello {  map[]} [] map[]}] { []  false map[] [] map[]} {[] [] []      map[] map[]} {     map[] map[]} { map[]} { map[]} [] {{[] map[]}  map[]} {[] [] [] []     {  map[]} [] map[]} {  }  map[]}
   • parallelism: 4
   • SETTING DEFAULTS
   • defaults set              config={ {ssh:/ false false {{.Tag}} map[]} { {goreleaserbot goreleaser@carlosbecker.com}    bin.install "gtrello" []  []   map[]} [{[windows darwin linux] [amd64] [6] [] . -s -w -X main.version={{.Version}} -X main.commit={{.Commit}} -X main.date={{.Date}}  gtrello {  map[]} [] map[]}] {tar.gz [] {{ .Binary }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}{{ if .Arm }}v{{ .Arm }}{{ end }} false map[] [licence* LICENCE* license* LICENSE* readme* README* changelog* CHANGELOG*] map[]} {[] [] []      map[] map[]} {     map[] map[]} {SNAPSHOT-{{ .Commit }} map[]} {{{ .ProjectName }}_{{ .Version }}_checksums.txt map[]} [] {{[] map[]}  map[]} {[] [] [] []     {  map[]} [] map[]} {  } dist map[]}
   • GETTING AND VALIDATING GIT STATE
   • releasing v1.0.1, commit a83042399b9ae815220b283d485da5a1d3d4d991
   • GENERATING CHANGELOG
   • LOADING ENVIRONMENT VARIABLES
   • CHECKING ./DIST
   • --rm-dist is set, removing ./dist
   • BUILDING BINARIES
   • building                  build={[windows darwin linux] [amd64] [6] [] . -s -w -X main.version={{.Version}} -X main.commit={{.Commit}} -X main.date={{.Date}}  gtrello {  map[]} [] map[]}
   • new binary                folder=_1.0.1_windows_amd64 name=gtrello.exe path=dist/_1.0.1_windows_amd64/gtrello.exe platform=windowsamd64
   • building                  binary=dist/_1.0.1_windows_amd64/gtrello.exe
   • new binary                folder=_1.0.1_linux_amd64 name=gtrello path=dist/_1.0.1_linux_amd64/gtrello platform=linuxamd64
   • building                  binary=dist/_1.0.1_linux_amd64/gtrello
   • new binary                folder=_1.0.1_darwin_amd64 name=gtrello path=dist/_1.0.1_darwin_amd64/gtrello platform=darwinamd64
   • building                  binary=dist/_1.0.1_darwin_amd64/gtrello
   • running                   cmd=[go build -ldflags=-s -w -X main.version=1.0.1 -X main.commit=a83042399b9ae815220b283d485da5a1d3d4d991 -X main.date=2017-10-21T03:32:07Z -o dist/_1.0.1_windows_amd64/gtrello.exe .] env=[GOOS=windows GOARCH=amd64 GOARM=] target=windows/amd64
   • running                   cmd=[go build -ldflags=-s -w -X main.version=1.0.1 -X main.commit=a83042399b9ae815220b283d485da5a1d3d4d991 -X main.date=2017-10-21T03:32:07Z -o dist/_1.0.1_linux_amd64/gtrello .] env=[GOOS=linux GOARCH=amd64 GOARM=] target=linux/amd64
   • running                   cmd=[go build -ldflags=-s -w -X main.version=1.0.1 -X main.commit=a83042399b9ae815220b283d485da5a1d3d4d991 -X main.date=2017-10-21T03:32:07Z -o dist/_1.0.1_darwin_amd64/gtrello .] env=[GOOS=darwin GOARCH=amd64 GOARM=] target=darwin/amd64
   • CREATING ARCHIVES
   • creating                  archive=dist/_1.0.1_linux_amd64.tar.gz
   • creating                  archive=dist/_1.0.1_darwin_amd64.tar.gz
   • creating                  archive=dist/_1.0.1_windows_amd64.tar.gz
   • new release artifact      artifact=_1.0.1_windows_amd64.tar.gz
   • new release artifact      artifact=_1.0.1_linux_amd64.tar.gz
   • new release artifact      artifact=_1.0.1_darwin_amd64.tar.gz
   • CREATING LINUX PACKAGES WITH FPM
   • skipped                   reason=no output formats configured
   • CREATING LINUX PACKAGES WITH SNAPCRAFT
   • skipped                   reason=no summary nor description were provided
   • CALCULATING CHECKSUMS
   • checksumming              file=_1.0.1_linux_amd64.tar.gz
   • checksumming              file=_1.0.1_darwin_amd64.tar.gz
   • checksumming              file=_1.0.1_windows_amd64.tar.gz
   • new release artifact      artifact=_1.0.1_checksums.txt
   • CREATING DOCKER IMAGES
   • skipped                   reason=docker section is not configured
   • RELEASING TO GITHUB
   • creating or updating release repo=ssh:/ tag=v1.0.1
   • release updated           url=
   ⨯ release failed            error=POST https://api.github.com/repos/ssh://releases: 404 Not Found []

Steps to Reproduce

[First Step]
set remote url ssh path in .git/config

% cat .git/config
[remote "origin"]
        url = ssh://git@github.com/midorigreen/gtrello.git
        fetch = +refs/heads/*:refs/remotes/origin/*

[Second Step]
run goreleaser

% goreleaser
.
.
   • release updated           url=
   ⨯ release failed            error=POST https://api.github.com/repos/ssh://releases: 404 Not Found []

[and so on...]
when set remote url https path in it, binary is uploaded to GitHub

% cat .git/config
[remote "origin"]
        url = https://github.com/midorigreen/gtrello.git
        fetch = +refs/heads/*:refs/remotes/origin/*

% goreleaser
.
.
   • release updated           url=https://github.com/midorigreen/gtrello/releases/tag/v1.0.1
.

Expected behavior: [What you expected to happen]
success release to GitHub
Actual behavior: [What actually happened]
failed release to GitHub

creating or updating release repo=ssh:/ tag=v1.0.1
repo is wrong
output
goreleaser/pipeline/release/release.go
 37     log.WithField("tag", ctx.Git.CurrentTag).
 38         WithField("repo", ctx.Config.Release.GitHub.String()).
 39         Info("creating or updating release")

goreleaser/config/config.go
 23 // Repo represents any kind of repo (github, gitlab, etc)
 24 type Repo struct {
 25     Owner string `yaml:",omitempty"`
 26     Name  string `yaml:",omitempty"`
 27
 28     // Capture all undefined fields and should be empty after loading
 29     XXX map[string]interface{} `yaml:",inline"`
 30 }
 31
 32 // String of the repo, e.g. owner/name
 33 func (r Repo) String() string {
 34     if r.Owner == "" && r.Name == "" {
 35         return ""
 36     }
 37     return r.Owner + "/" + r.Name
 38 }

Follow setting is success
.goreleaser.yml
% cat .goreleaser.yml
# .goreleaser.yml
# Build customization
builds:
  - binary: gtrello
    goos:
      - windows
      - darwin
      - linux
    goarch:
      - amd64

# Release customization
release:
  github:
    owner: midorigreen
    name: gtrello

% goreleaser -rm-dist
   • running goreleaser 0.35.4
   • loading config file       file=.goreleaser.yml
   • SETTING DEFAULTS
   • GETTING AND VALIDATING GIT STATE
   • releasing v1.0.2, commit 57b17e9a6a2400aa0ab4e0f1220a82d9f634e24f
   • GENERATING CHANGELOG
   • LOADING ENVIRONMENT VARIABLES
   • CHECKING ./DIST
   • --rm-dist is set, removing ./dist
   • BUILDING BINARIES
   • building                  binary=dist/gtrello_1.0.2_windows_amd64/gtrello.exe
   • building                  binary=dist/gtrello_1.0.2_darwin_amd64/gtrello
   • building                  binary=dist/gtrello_1.0.2_linux_amd64/gtrello
   • CREATING ARCHIVES
   • creating                  archive=dist/gtrello_1.0.2_linux_amd64.tar.gz
   • creating                  archive=dist/gtrello_1.0.2_windows_amd64.tar.gz
   • creating                  archive=dist/gtrello_1.0.2_darwin_amd64.tar.gz
   • new release artifact      artifact=gtrello_1.0.2_windows_amd64.tar.gz
   • new release artifact      artifact=gtrello_1.0.2_linux_amd64.tar.gz
   • new release artifact      artifact=gtrello_1.0.2_darwin_amd64.tar.gz
   • CREATING LINUX PACKAGES WITH FPM
   • skipped                   reason=no output formats configured
   • CREATING LINUX PACKAGES WITH SNAPCRAFT
   • skipped                   reason=no summary nor description were provided
   • CALCULATING CHECKSUMS
   • checksumming              file=gtrello_1.0.2_darwin_amd64.tar.gz
   • checksumming              file=gtrello_1.0.2_windows_amd64.tar.gz
   • checksumming              file=gtrello_1.0.2_linux_amd64.tar.gz
   • new release artifact      artifact=gtrello_1.0.2_checksums.txt
   • CREATING DOCKER IMAGES
   • skipped                   reason=docker section is not configured
   • RELEASING TO GITHUB
   • creating or updating release repo=midorigreen/gtrello tag=v1.0.2
   • release updated           url=https://github.com/midorigreen/gtrello/releases/tag/v1.0.2
   • uploading to release      file=dist/gtrello_1.0.2_checksums.txt name=gtrello_1.0.2_checksums.txt
   • uploading to release      file=dist/gtrello_1.0.2_linux_amd64.tar.gz name=gtrello_1.0.2_linux_amd64.tar.gz
   • uploading to release      file=dist/gtrello_1.0.2_windows_amd64.tar.gz name=gtrello_1.0.2_windows_amd64.tar.gz
   • uploading to release      file=dist/gtrello_1.0.2_darwin_amd64.tar.gz name=gtrello_1.0.2_darwin_amd64.tar.gz
   • CREATING HOMEBREW FORMULA
   • skipped                   reason=brew section is not configured
   • SUCCESS!

Cause discoverd
follow extractRepoFromURL(s string) don't correspond format ssh://git@github.com
pipeline/defaults/remote.go
 23 func extractRepoFromURL(s string) config.Repo {
 24     for _, r := range []string{
 25         "git@github.com:",
 26         ".git",
 27         "https://github.com/",
 28         "\n",
 29     } {
 30         s = strings.Replace(s, r, "", -1)
 31     }
 32     return toRepo(s)
 33 }

Run() call setReleaseDefaults(ctx) -> extractRepoFromURL(s string)
 34 // Run the pipe
 35 func (Pipe) Run(ctx *context.Context) error { // nolint: gocyclo

 46     if err := setReleaseDefaults(ctx); err != nil {

repo: midorigreen/goreleaser


text:
middleware/metrics improvements

Feature requests for the metrics middleware (most of it is already here, but we should double check and fix).

histogram of time to resolve upstream queries
running number of queries
running number of NXDOMAIN
number of elements in cache (broken down by positive and negative, maybe)
breakdown of queries by type (A, SRV, PTR, ...)
running average QPS over the last 10 seconds (not sure if we should export this, or leave that to the monitoring system)

We the new auto middleware should export the number of zones found.
Per middleware exporting of metrics? Think that makes sense.

#335 adds

number of elements in cache (broken down by positive and negative, maybe)

The rest is all implemented, we should only fix #346

If you use the auto middleware, new zones won't be monitored as the metrics middleware does not know about them.
We need some kind of dynamic zone registration for this this.

.. And we need an Active(middleware string) bool function that returns true if a middleware is activated. This way we can hook into a middleware and call some it's public methods.

repo: miekg/coredns

license_source: bigquery


text:
TXT query on cloudflare.com returns empty answer

Hi,
I have a weird issue:
When I query cloudflare.com for TXT records I get an empty answer instead of the expected records.
The same query using dig and the same dns server returns the expected records.
The TXT query works for all domains I tested except cloudflare.com. I've also tried using different dns servers with no luck.
Am I doing something wrong on my end or is this just a weird bug?
How to reproduce
package main

import (
	"github.com/miekg/dns"
	"log"
)

func main()  {

	c := dns.Client{}
	m := dns.Msg{}
	m.SetQuestion("cloudflare.com.", dns.TypeTXT)
	r, _, err := c.Exchange(&m, "1.1.1.1:53")
	if err != nil {
		log.Fatal(err)
	}
	log.Print(r)

}

Ghe, I was mystified as well, but cloudflare sets Tc:
;; flags: qr tc rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

not putting anything in the answer is borderline RFC incompliant though...

/close

Ah, thanks for the response. Must have missed the truncate flag.

repo: miekg/dns


text:
Add support to qwik icons

Hi, can you add Qwik icon support to js, jsx, ts and tsx files extensions?
Qwik main page
Qwik icon
Thanks for you work Miguel!

@falvarador Thanks for the request, I'm not too familiar with this and wasn't able to find specific file types for these. Can you link to any examples and include what file extensions they use? You mention js/jsx/ts but those have their own file icons. Thanks!

If you ever get a list of file types let me know, otherwise I'll be closing this issue.

authors: falvarador miguelsolorio

repo: miguelsolorio/vscode-symbols


text:
No notifications on macOS after build

I am getting notifications in my Electron app when it is in dev mode, but after it is built there are no notifications present.
I have my build setup with:
  node: {
    __filename: true,
    __dirname: true
  },

to account for webpacker and I also have my development and distribution profiles setup in Xcode which are detected during an Electron build. So I can (mostly) eliminate most of the common Electron and electron-builder issues that could cause node-notifier to be a problem.
Any thoughts here? I have no errors in the Console logging app.
What could be causing this?

Any thoughts?

the same here

the same problem on windows

Same problem here on macOS. When in dev mode it works fine, but when prod it doesnt' work.
It is working in dev mode even though I have:
  node: {
    __dirname: false,
    __filename: false
  },

same here

My package.json
{
  …
  "main": "main.js",
  "scripts": {
    "postinstall": "electron-builder install-app-deps",
    "start": "electron main.js",
    "pack": "build --dir",
    "dist": "build"
  },
  "build": {
    "appId": "my.app.id",
    "dmg": {
      "contents": [
        {
          "x": 110,
          "y": 270
        },
        {
          "x": 370,
          "y": 270,
          "type": "link",
          "path": "/Applications"
        }
      ]
    },
    "mac": {
      "category": "productivity",
      "extendInfo": {
        "CFBundleURLName": "myapp",
        "CFBundleURLSchemes": [
          "myapp"
        ]
      }
    },
  },
  "dependencies": {
    "electron-is-dev": "^1.1.0",
    "electron-updater": "^4.0.6",
    "electron-window-state": "^5.0.3",
    "node-notifier": "^5.4.0",
    "url-parse": "^1.4.6"
  },
  "devDependencies": {
    "asar": "^1.0.0",
    "electron": "^4.1.4",
    "electron-builder": "^20.39.0",
    "electron-packager": "^13.1.1",
    "electron-reloader": "^0.2.0"
  }
}

@mikaelbr
I tried with this instruction : https://github.com/mikaelbr/node-notifier#within-electron-packaging.
That generates very heavy .dmg and .zip files, and node-notifier still don't work.

After working one full day on node-notifier problems with Electron, i chose to use node-mac-notifier which works great under production.
node-notifier library seems powerful and has many stars, but many people seems to face build problems, even for windows.
As an example Slack use node-mac-notifier and electron-windows-notifications which are stable versions, even for very old versions of Electron. You don't have as many options but that's works.

You may need this: node-notifier-in-electron-vue

@ReAlign that's interesting, thanks for sharing. Even if wearen't using Vue though?

@Noitidart no, it‘s is just a simple handling of the situation ,
I am just simple processing, ensure that can be used.

I fixed it with "asar": false in my build config

@Noitidart  add asarUnpack option to electron-builder
"build": {
    "asarUnpack": [
      "./node_modules/node-notifier/vendor/**"
    ],
    ...
}

@leekangtaqi Thanks! You made my day!!

authors: Aarbel Ghefest GyuCheol Ivorfason Noitidart ReAlign kevinelliott leekangtaqi pablopunk

repo: mikaelbr/node-notifier

license: mit


text:
Various issue with snapshotting

The staging table that the merge statement needs was being dropped prior to the merge statement running. (snapshot.sql)
The column list in the Insert section of the merge statement ended up with duplicate columns. (adapters.sql)

This issue is solved in the current master branch. I am planning to release it as v0.15.3.1. I close this issue but feel free to reopen if it still don't work for you.

authors: kofoide mikaelene

repo: mikaelene/dbt-sqlserver


text:
bufferline.nvim doesn't show buffers when opening multiple files if also using dashboard-nvim

As discussed in https://github.com/mikavilpas/yazi.nvim/commit/5cd3ad7ef02053d1360b9521d473f8f5a7ac7c3f

% nvim -v
NVIM v0.11.0-dev-572+gac24b907f-dirty

With the following repro.lua:
-- You can use this file to reproduce an issue with your configuration.

---@module "yazi"
---@module "lazy"

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)
vim.g.mapleader = " "

-- install the following plugins
---@type LazySpec
local plugins = {
  "folke/tokyonight.nvim",
  {
    "mikavilpas/yazi.nvim",
    event = "VeryLazy",
    keys = {
      {
        -- 👇 choose your own keymapping
        "<leader>e",
        function()
          require("yazi").yazi()
        end,

        { desc = "Open the file manager" },
      },
      opts = {
        open_for_directories = false,
      },
    },
  },
  {
    "nvimdev/dashboard-nvim",
    event = "VimEnter",
    opts = {},
  },
  {
    "akinsho/bufferline.nvim",
    dependencies = "nvim-tree/nvim-web-devicons",
    event = { "BufAdd", "BufRead", "BufNewFile" },
    opts = {
      options = {
        always_show_bufferline = false,
      },
    },
  },
  ---@type YaziConfig
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")

nvim -u repro.lua
Open yazi
Create two test files
Select them and press Enter to open them
buffers from bufferline.nvim aren't displayed but :buffers lists them
Disable dashboard-nvim:

  {
    "nvimdev/dashboard-nvim",
    enabled = false,
    event = "VimEnter",
    opts = {},
  },

Repeat 2. and 4. - buffers from bufferline.nvim appears correctly

I also tried always_show_bufferline = false, for bufferline.nvim but it doesn't make any difference:
{
    "akinsho/bufferline.nvim",
    dependencies = "nvim-tree/nvim-web-devicons",
    event = { "BufAdd", "BufRead", "BufNewFile" },
    opts = {
      options = {
        always_show_bufferline = false,
      },
    },
  },

Looks like this https://github.com/nvimdev/dashboard-nvim/issues/274#issuecomment-1407953537
It works if I set this
diff --git a/repro.lua b/repro.lua
index 9efd04b..e810b5c 100644
--- a/repro.lua
+++ b/repro.lua
@@ -50,7 +50,11 @@ local plugins = {
   {
     'nvimdev/dashboard-nvim',
     event = 'VimEnter',
-    opts = {},
+    opts = {
+      hide = {
+        tabline = false,
+      },
+    },
   },
   {
     'akinsho/bufferline.nvim',

Can you verify this?

authors: mikavilpas xfzv


text:
Does not work with VS2017 (15.9.15)

Hi. This package fails to load Microsoft.VisualStudio.Shell.15.0, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
See error in attached file.
Error.txt

Workaround: Revert to https://github.com/mike-ward/VSColorOutput/releases/tag/v2.6.4

authors: CADbloke LaoR-UA

repo: mike-ward/VSColorOutput


text:
Updated exec-sh package to latest which fixes a known vulnerability

The exec-sh package used a package with a disclosed security vulnerability, see https://hackerone.com/reports/381194.
This has now been removed in the latest version 0.3.2

any reason why this is not merged?

repo: mikeal/watch


text:
Cannot show output after Tuesday afternoon dropped

Things to check

Have you forced a refresh in your browser (e.g. ctrl+F5 in Chrome/Firefox)?

yes/no

Have you made sure the first time buyer option is correct? If you're unsure, try it both ways

yes/no

Have you time-travelled this week? Travelling backwards resets the prices, and therefore you must not put prices in from both before & after the time-travel

yes/no

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Permalink to your prices
Please click the Copy Permalink button and paste it here
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

On iPhone SE, safari browser. Input Tuesday afternoon’s number and received an error. Output was predicted to be higher, but input was lower than expected (actual price in town)

Nevermind. I realized I misread the first question as if it was the first time I had bought turnips. Another resident had bought turnips before.

Closing issue for now since the bug report template wasn't filled in. Since there are many reports, please reply if you've posted more information so that the problem can be investigated.

repo: mikebryant/ac-nh-turnip-prices


text:
rake requires 1.9.3 starting with v11.0.0

This should make travis green again on ruby 1.9.2 and below

This has passed Travis now. Please merge so new branches can get accurate Travis runs.
Thanks!

@jeremy or @bf4 can you please merge this or something like it to bring master back to green so that future PRs can be properly evaluated for errors.

Yes.
On Fri, Apr 1, 2016 at 07:25 Kevin Glowacz notifications@github.com wrote:

@jeremy https://github.com/jeremy or @bf4 https://github.com/bf4 can
you please merge this or something like it to bring master back to green so
that future PRs can be properly evaluated for errors.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/mikel/mail/pull/979#issuecomment-204416032

Backported to 2-6-stable

authors: jeremy kjg

repo: mikel/mail


text:
Skipping texture processing as converter.dirname is empty or invalid

I am using usd2gltf to convert a USDZ file to GLTF. The tool works well when I run it in a console, successfully converting the USDZ file with embedded textures. However, when running the same conversion in a FastAPI script, I encounter the following issue where textures are skipped during the conversion:
Skipping texture processing as converter.dirname is empty or invalid.
Logs from FastAPI Execution:

Length of USDZ file content: 9261065 bytes
USDZ file written to temporary path: /tmp/temp_usdz.usdz
Temporary USDZ file size: 9261065 bytes
Running command: /home/ec2-user/venv/bin/usd2gltf -d -i /tmp/temp_usdz.usdz -o ./PS5.glb -f
Standard Output:
Converting: /tmp/temp_usdz.usdz
To: ./PS5.glb
Skipping texture processing as converter.dirname is empty or invalid.
Skipping texture processing as converter.dirname is empty or invalid.
Skipping texture processing as converter.dirname is empty or invalid.
Converted!
GLB file size 2.3 MB without textures

Console Output (Working Scenario):
When running usd2gltf in the console, the conversion works as expected and the textures are embedded:
usd2gltf -d -i "PS5.usdz" -o "PS5.glb"
Console log includes texture embedding:

DEBUG:usd2gltf.converter:Embeded res: FileResource("baked_mesh_93702174_tex0.png")
DEBUG:usd2gltf.converter:Embeded res: FileResource("baked_mesh_93702174_ao0.png")
Converted!
GLB file size 11.3 MB with textures

Environment Details:

•	usd2gltf Version: 0.3.5
•	Python Version: 3.9
•	Operating System: Amazon lightsail running Amazon Linux
•	Execution Environment:
•	Working in console (inside a virtual environment)
•	Issue occurs when running in FastAPI (inside the same virtual environment)

I understood what the problem was.
Running command: /home/ec2-user/venv/bin/usd2gltf -d -i /tmp/temp_usdz.usdz -o ./PS5.glb -f
Wrong OUTPUT
./PS5.glb
Correct OUTPUT
PS5.glb
Funny thing is that the script doesn't have any problem with the wrong path for geometry.bin and successfully converts the file without textures.


text:
the font color should use styleguide definition

The font color for primary text is 87% of black: #de000000
BUT why not adjustable? -> .setDescriptionFontColor(R.color.xyz)

@Rainer-Lang right now the colors can be configured by adding a colors.xml to your application and set the different colors to custom values:
<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!-- Theme colors -->
    <color name="theme_default_primary">#536dfe</color>
    <color name="theme_default_primary_dark">#3f51b5</color>
    <color name="theme_accent">#ff4081</color>
    <color name="theme_window_background">#ECECEC</color>

    <!-- AboutLibraries DEFAULT colors -->
    <color name="about_libraries_card">#FAFAFA</color>
    <color name="about_libraries_title_openSource">#212121</color>
    <color name="about_libraries_text_openSource">#727272</color>
    <color name="about_libraries_dividerDark_openSource">#AAA</color>
    <color name="about_libraries_dividerLight_openSource">#DADADA</color>

    <!-- AboutLibraries SAMPLE DARK colors -->
    <!--
    <color name="theme_window_background">#303030</color>
    <color name="about_libraries_card">#666666</color>
    <color name="about_libraries_title_openSource">#ffffffff</color>
    <color name="about_libraries_text_openSource">#DEDEDE</color>
    <color name="about_libraries_dividerDark_openSource">#303030</color>
    <color name="about_libraries_dividerLight_openSource">#303030</color>
    -->
</resources>

Is it possible to add this in the README? ;-)

The original colors are from here: http://www.materialpalette.com/blue/pink

It's now in the wiki ;)
https://github.com/mikepenz/AboutLibraries/wiki/HOWTO:-Style

authors: Rainer-Lang mikepenz

repo: mikepenz/AboutLibraries