Comments (8)
I'm not sure that using winget
inside of an installer is a valid use case, and I personally would recommend against it.
Although WinGet is included in many OS builds now, there is no guarantee that a user's configuration will support it. For example, a user could have removed all the default sources and added their own private source which doesn't have Git.Git
. Some users could still be on an older 1.6 version of WinGet that can't install anything due to an outdated CDN (requiring them to manually update WinGet first). A new version of Git submitted to WinGet could break your installation flow. There's many other scenarios that could break your install if you take a dependency on WinGet or on the WinGet source. In an enterprise scenario, WinGet could be blocked by Group Policy. In the future Git could decide they want to remove all their manifests from the WinGet source, thereby making it unavailable. A hash mismatch on the Git download would cause the install to fail. Some users could manually remove WinGet from their machine if they try hard enough.
from winget-cli.
It's in the natur of a software developer to question the approach rather than giving a suggestion to solve it. No worries, I do in fact install winget on the system.
The issue seems to be similar to: #1433
Is this related to adding the manifest due lack of permission?
from winget-cli.
WinGet has a notion of dependencies in the manifest to handle installing any other packages with dependencies from the same source.
This appears to be a scenario where the installer is looking to leverage WinGet to install dependencies "inside" the installer. I'd like to understand the scenario a bit more here.
The Microsoft Store has their own policies regarding what an installer is doing, and there are several other automated processes evaluating what is being installed on a system during package installation flows.
from winget-cli.
This appears to be a scenario where the installer is looking to leverage WinGet to install dependencies "inside" the installer. I'd like to understand the scenario a bit more here.
Do I understand correct, that you like to know the scenario of using winget? I took this installation guide and wrote a nullsoft installer to automate everything for end-users.
I could just use PowerShell to download and install everything, but a package manager is more elegant in my opinion.
The Microsoft Store has their own policies regarding what an installer is doing, and there are several other automated processes evaluating what is being installed on a system during package installation flows.
I tried to work with --scope user
but this did not work.
from winget-cli.
I see a few potential challenges with the way this is being called by nsexec command.
- The first is the explicit path for WinGet may change or may not be valid.
- The second is that no source is being specified which means if the user doesn't have the default source your application is expecting, it would fail, or unintentionally install a package from another source.
- The "--accept-source-agreements" is an "explicit" call a user may not be making or intending to make when the package is installed, and if package agreements are required, they also would not be handled via explicit consent.
Getting past the technical challenges should be possible.
If the installer is depending on WinGet to handle dependencies, I'd suggest leveraging the COM APIs in WinGet rather than calling the executable. If this package is only going to be used by the Microsoft Store for distribution, then it's reasonably safe to assume WinGet is present on the system, since the Microsoft Store client is leveraging WinGet to perform the WIn32 installation.
We still have work to do in WinGet to expose the sources to the COM API so they can be validated before a call fails during installation. You could test by using winget source remove winget
and then running the installer to test that scenario.
There are also Group Policies an enterprise could configure to prevent calls to winget.exe. That would also cause the installation of the dependency to fail. You can set the policies, and run winget --info
to see which policies are configured.
As far as the agreements go, that's a bit of a stickier problem. I'm not able to offer legal advice, so I'd check to make sure liabilities can be avoided. I'd expect an application installing other applications to inform me and give me the ability to agree or cancel. If consent is given up front, then the need to prompt for those dependencies may be something that can be eliminated, but again, I'd get legal advice before proceeding on that front.
from winget-cli.
Thank you for bringing up the legal considerations regarding the installer that I need to address. I was not aware of it, but will fix it in the future.
I'm not sure if I understand you correct but the WinGet install script has been added to cover Windows 10 users. The current issue we have are the conflict with the MS Store's instance of WinGet on their server.
Right before you responded, I did another run using --verbose-logs
.
WPM_89862289_92d6281ace9434050b96d2fc8a63888f59d06ee1de2440cbc34c2e2d7253d32c.txt
Removing the winget
source will cause the package not to be found!? I just tried it and the silent check is passing - this is false positive because nothing has been installed.
Unfortunately no access to logs in that case.
I tried ealier this day to limit the source to winget - it then ignored the msstore source but I assume writting down the winget manifest (or whetever it does) causes the fatal error.
from winget-cli.
I'm guessing here since I don't know exactly what the environment validation is happening in for the Microsoft Store. I'd expect either the client in validation for the "msstore" source either doesn't have the default "winget" source enabled/configured, or when the command is being executed, it's not happening "inline", but it's launching a window to run the command. Unfortunately, I don't have a way to determine that. I'll have to reach out to someone on the store team. Either way, this kind of cross-source dependency may be prohibited by some kind of policy.
Can you send me an e-mail so I can forward the thread to the store team?
from winget-cli.
I gave up on the MS Store due this issue and the restriction that everything being installed via winget is considered as bloatware.
from winget-cli.
Related Issues (20)
- Support input file containing list of software for 'download' feature HOT 1
- WinGet configure should look for a default config file if none is provided HOT 1
- Winget Configuration Export should support more than one ID HOT 1
- Winget Configuration Export should support over write HOT 1
- The `Get-WinGetPackage` and `Get-WinGetPackageUpdate` cmdlets do not report anymore the package name HOT 3
- Gibberish and inconsistencies in package IDs HOT 2
- WinGet installation of 7Zip: 0x80070005 : unknown error HOT 4
- Add a more comfortable installation method as AppImage does. HOT 11
- Add `<PACKAGEVERSION>` token
- Truncated message warning should be yellow not red.
- `--scope machine` for zip install type incorrectly inherits permissions HOT 2
- Winget Download Merged Yaml broken HOT 1
- Add `--exclude` option to `upgrade` command to exclude a specific app when upgrading packages using `--all` HOT 3
- Offline install capability HOT 2
- WDK and SDK Side by Side installs do not work correctly HOT 1
- where are windows server 2022 installation instructions? HOT 2
- Issue with --exact feature not working as expected HOT 2
- Microsoft.Management.Deployment.Projection should be included in Microsoft.WindowsPackageManager.ComInterop NuGet HOT 1
- Add an option to "hide" or not download when "upgrade --all" is run. HOT 2
- Garbled output when doing `winget list --source winget | Sort-Object Name` in pwsh with windows language set to russian HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from winget-cli.