
Windows Package Manager Preview - zeusly
https://devblogs.microsoft.com/commandline/windows-package-manager-preview
======
phiresky
... this thing literally just downloads .exe files and then executes them.
There's no dependency management.

Look at the firefox "package": [https://github.com/microsoft/winget-
pkgs/blob/master/manifes...](https://github.com/microsoft/winget-
pkgs/blob/master/manifests/Mozilla/Firefox/75.0.yaml)

There isn't even any uninstall functionality.

This is a package manager as much as a piece of cardboard is a swiss army
knife.

Even if you say "but it's a preview", there's just no where to go when your
starting point is "execute some arbitrary binary". The point of packages is to
be declarative as much as possible.

~~~
alkonaut
Would dependency management really make much sense on Windows?

Under normal circumstances you share as little as possible. There isn’t a
situation where an app needs “library X version Y or greater”.

Some runtimes etc is usually all that’s shared.

~~~
r00fus
Has this changed from the 90s/2000s? I've been on Lin/Mac for the past decade,
but back then many libraries (DLLs) required (msxml4.dll, msvbvm50.dll) - note
specific versions.

~~~
plorkyeran
Windows has supported installing multiple versions of the same system library
ever since Windows XP via WinSxS. It's been a non-issue for a long time.

~~~
alkonaut
Still, for application developers the idea of installing "system-wide
libraries" is all but gone. An application installer will just install to
\Programs and that's normally it, even for very large applications (Obviously
something system-y like a driver still installs system files). Even things
that used to be typical system things like runtimes (C++, .NET) can now be
locally deployed, which is nice.

In the 90's it wasn't uncommon for installers to just poop application files
or config files into Windows\System32.

------
open-paren
This[1] is the repository from which it pulls. It sounds like third-party
repos are a planned feature. Basically, every package is a yaml file like
this:

    
    
      Id: string # publisher.package format
      Publisher: string # the name of the publisher
      Name: string # the name of the application
      Version: string # version numbering format
      License: string # the open source license or copyright
      InstallerType: string # enumeration of supported installer types (exe, msi, msix)
      Installers:
        - Arch: string # enumeration of supported architectures
          URL: string # path to download installation file
          Sha256: string # SHA256 calculated from installer
      # ManifestVersion: 0.1.0
    
    

Doesn't look like there is field for dependencies of a package, but this is
also a 0.1.0 release.

[1]: [https://github.com/microsoft/winget-
pkgs](https://github.com/microsoft/winget-pkgs)

~~~
DaiPlusPlus
YAML? That’s very surprising to me (I grew up in the XML-for-everything days).
Would this be the first-ever first-party Microsoft project to use YAML?

~~~
modernerd
Not sure about YAML, but I was happy to see Windows Terminal use JSON for
configuration instead of XML.

[https://github.com/microsoft/terminal/blob/master/doc/user-d...](https://github.com/microsoft/terminal/blob/master/doc/user-
docs/UsingJsonSettings.md)

~~~
lillesvin
VS Code also uses JSON for configuration, IIRC.

~~~
modernerd
Yes, it uses jsonc (“JSON with Comments”), which is even better. :-)

[https://code.visualstudio.com/docs/languages/json](https://code.visualstudio.com/docs/languages/json)

------
ocdtrekkie
I found the issue I think Microsoft is going to actually foul up poorly here,
which I... went ahead and filed an issue on:
[https://github.com/microsoft/winget-
pkgs/issues/288](https://github.com/microsoft/winget-pkgs/issues/288)

In short, a Microsoft employee added AdoptOpenJDK 8 to the repo. ...Java 8?
...In 2020? Another user has opened a PR to add what looks like the FSF's
OpenJDK 14 to the repo. So are we supporting 8 or 14? Are users who want to
"winget install openjdk" going to get 8 or 14, Adopt or FSF?

I doubt Microsoft is willing to pick winners or losers or opinionate on the
authority of third party package sources, and hence, the dream of "winget
install powertoys" will probably only reliably do what it should for Microsoft
tools.

~~~
karianna
This was a bug of sorts, we’ve engaged the Java team at Microsoft to get this
sorted. Disclaimer - I run the Java team at Microsoft

~~~
ocdtrekkie
Good to hear. While I noticed Java as the example here, I feel this does speak
to a general issue about how to handle multiple releases and some of the
decision-making the Package Manager team is going to need to have in place
before this leaves preview. For winget to be not just useful, but trusted, it
needs to make decisions, not just be an open dumping ground for package
installers.

The decisions the team chooses will end up informing the community on the
reliability of it as a platform. And I'm definitely excited to see what
happens here!

------
eclipsetheworld
I'd recommend to take a look at the project's roadmap to get an idea where
Microsoft is going with this:

[https://github.com/microsoft/winget-
cli/blob/master/doc/wind...](https://github.com/microsoft/winget-
cli/blob/master/doc/windows-package-manager-v1-roadmap.md)

------
Congeec
I'm pretty satisfied with the package manager scoop. Scoop for now works best
when you just install binary software. It is not a replacement for package
managers like vcpkg yet with which you can pull dev dependencies for a
project.

How does winget compare to scoop? Does it replace vcpkg/nuget/conan/...?

~~~
pas
Anyone else looking to try scoop should be familiar with this list:
[https://rasa.github.io/scoop-directory/by-
score](https://rasa.github.io/scoop-directory/by-score)

------
lrpublic
I like scoop, and this is a show stopper for me.

"This project collects usage data and sends it to Microsoft to help improve
our products and services. See the privacy statement for more details." from
[https://github.com/microsoft/winget-cli](https://github.com/microsoft/winget-
cli)

~~~
nojito
Why is that a showstopper?

People do not give feedback so it's impossible to tell how their programs are
being used.

The other choice is to listen to the vocal minority that offers feedback than
you get into issues of implementing features that no one wants/uses.

~~~
lrpublic
It's not opt-in, so quite likely a breach of GDPR.

The telemetry in question seems to be logging what is installed, not just how
the application is used.

Regardless of consumers willingness to provide feedback it's not a reasonable
choice for a large software vendor to collect data from customers computers
about competitors products.

~~~
nojito
It’s logging what’s used so that the app can be improved to fit the use cases
of its users.

Of course it’s reasonable. The other choice is developing blindly or listening
to the vocal minority. Both of which hurt ALL users in the end.

~~~
lawnchair_larry
Software has always been developed that way and it has never been a problem.
It’s only recently that developers somehow got the idea that they are entitled
to perform surveillance on their customers. It’s nonsense.

~~~
naikrovek
> Software has always been developed that way and it has never been a problem.

It's always been a problem, most people just don't know that because the
majority of users don't express their concerns in the way(s) that the
developers are open to hearing those concerns.

------
milkthefat
Most of the responses here do a really great job at pointing out the flaws of
this project. My biggest gripe is it currently has no plans to be integrated
by default. So just like all the other package management tools for windows
the tool itself is a prereq requiring another hoop. If I have to deal with
more configuration management to install this from the app store I’d rather
use chocolaty at least that can be installed reliably.

------
charlesdaniels
I'm not a Windows user... but didn't they already do this with OneGet? Did
that get deprecated? Is this just a re-branding?

~~~
GordonS
I'm a Windows user, but I've never even heard of OneGet?

~~~
charlesdaniels
This one, as I recollect: [https://docs.microsoft.com/en-
us/powershell/module/microsoft...](https://docs.microsoft.com/en-
us/powershell/module/microsoft.powershell.core/about/about_packagemanagement?view=powershell-7)

------
6c696e7578
So in 199{7,8,9}? I was using yast and/or apt-get to get packages. That was
>20 years ago. Now MS have offered something like tar.gz of binaries without
dependencies.

But I guess this is an answer to the "where's package management" question.
Still not there.

~~~
recursive
All the dependencies are just in the original thing. I have very limited
experience with Linux but chasing down problems with dependencies of
dependencies feels like a special circle of hell to me.

~~~
6c696e7578
> chasing down problems with dependencies of dependencies feels like a special
> circle of hell to me.

Were you getting source from author sites or using the package manager?

I've never had problems with apt or yum. In the days before yum it was a
different story in Red Hat. Debian have always had it right with apt IMO. You
could attribute the success of Ubuntu to it I feel.

~~~
recursive
I don't remember. I tried to do some rails development in linux like 10 years
ago. I know I was using apt, or at least started there. I don't think I ever
even got the environment running. I'm sure I was doing something wrong, so no
need to blame me, I already know.

------
nailer
How does this relate to `install-package`, the Microsoft-official 'package
manager for package managers' released a few years ago?

~~~
techntoke
Microsoft would be much better off if they had a YAML format for creating
Windows installations, as opposed to their current unattended installs.

------
alexeiz
Frankly, this is a very lame attempt at the package manager. All it does is
download installer executables and run them. There is no ability to list
installed packages, neither is the ability to uninstall. Where's the actual
package management functionality?

Both Scoop and Choco are way better than this.

------
mavhc
It mentions oneget, isn't that nuget now? and also by Microsoft?

------
ruffrey
It talks about installing apps. But what about DLLs? .NET framework versions?

~~~
pjmlp
It has been ages that the best practices are to install them alongside the
applications instead of polluting C:\Windows.

Also .NET Core is supposed to be bundled with the application.

~~~
rbanffy
Unfortunately, this causes file duplication (which is not that bad these days
of endless storage) and unnecessary vulnerabilities when outdated vendored
libraries are used by applications.

Linux distributions tend to keep shared libraries in their own packages and
applications depend on them so that when you install an app, the packages with
the libraries also get installed. And all packages in the distribution tend to
use the same versions of those shared libraries.

~~~
pjmlp
Which is why nowadays Linux suffers more from .so hell and ABI breakages than
Windows does.

~~~
derefr
Not really? In the Debian ecosystem, at least (can't speak for any other),
every major version of a library package is expected to be packaged as its own
separate concurrently-installable package. You'll find e.g. postgresql-11-dev
and postgresql-12-dev both exist as packages, and one provides libpq.11.y.z.so
+ its headers, while the other provides libpq.12.y.z.so + its headers. Each
gets updates independently. One will never automatically switch you over to
the other.

And major versions are the only things that _need_ to be separately packaged,
because the Linux native-library ecosystem is expected to keep .so ABI
compatibility through both "patch" and "minor" updates (the only difference
between the two being that "minor" updates can add new exported symbols to the
library; they still should not break usages of existing symbols.) This
particular arrangement was, in fact, what the Semantic Versioning standard was
introduced to accomplish—getting upstream developers to use their version-
tuples to mean the same things that Linux-distro package maintainers expect
them to mean, allow Linux-distro package maintainers to reuse upstream version
schemes rather than needing to maintain their own.

~~~
kasabali
All true _in theory_ , but in practice these mechanisms are worthless because
for most libraries Debian developers are dropping older version of libraries
immediately after transition to the new version is completed. Want to to run a
3rd party binary that depends on an older library? You're favorite package was
dropped during the transition? Tough luck. Your best bet is installing needed
library packages from previous debian release and praying that'll work.

~~~
derefr
True enough, but if stability is your desire, that is precisely why distros
cut releases (and especially LTS releases) in the first place. If you want a
program that can run without ABI-conformance changes for years and years, base
it on an LTS release, and that LTS release will keep whatever ABI-major
versions of the .so library-packages it shipped with updated (with security
updates, at least) until the release's EOL. If you don't want ABI breakage,
then _don 't dist-upgrade_!

But, this is also to say: if you're creating a new, greenfield project, or a
new major version of your own app—and you haven't yet deployed it into the
wild as a fixed binary that people rely on to continue running on their boxes
between upgrades—then nobody else but you has any incentive to keep things
stable for you. If you want to develop against the newest Debian release at
any given time, then it's up to you to catch up to whatever the newest ABI-
major versions of your deps are at any given time. That's a problem you've
chosen for yourself.

------
eigenvalue
I’m sure the developers of Chocolatey have been dreading this day for years.

~~~
STRML
Dreading? I doubt it. It's a relief when the problem your library solves no
longer needs solving!

~~~
_-david-_
If it was just a free library that would be one thing but they have a company
with multiple employees.

~~~
saxonww
I won't say it was silly to ever make Chocolatey, but it was living on
borrowed time from day one.

What's interesting to me about this announcement is that it seems to replace
something they already had; Microsoft released OneGet several years ago and
was positioning it (I thought) the same way they are positioning this. It's in
maintenance mode now. So I would say Chocolatey is doomed only if this
actually sticks.

------
rkagerer
Software management on Windows is such a mess.

After decades of opportunity for improvement, it's largely gotten worse.
Uninstall is too often a myth, and the majority of programs out there leave
bits and pieces behind. These add up over time to bloat your registry, disk,
kernel drivers, etc, degrading the performance and reliability of your
computer. Multiple conventions for where things go makes it difficult to track
down the bits. (Program Files? (x86)? AppData\\[Local|LocalLow|Roaming]?
SteamApps\common? ProgramData? System32/SysWOW64? Dozens of registry
locations?)

So many installers require unfettered, administrative access to my computer
with little indication of exactly what they intend to do (Litter my desktop
with new shortcuts? Add shell hooks? Install a rootkit?) and no opportunity
from the OS to consent your partial permission or retroactively examine the
changes. (Don't miss that popup balloon about a new driver! Have fun parsing
through all the noise in your event logs).

Even simple chores like managing file type associations became more painful
somewhere along the way.

There's a reason professionals so often fall back to advising a reformat.
Makes me miss the days when your program went someplace like C:\PHOTOSHOP and
most everything for it was contained within.

It's easy to point fingers at individual software publishers (I've called out
some incompetent ones) but mostly I blame Microsoft for failing to evangelize
rigorously thought-through best practices and provide better tooling to make
it dead easy for developers to get it right. I might be wrong about this, but
the preview looks like a gimmick for finding and running installers. I would
have liked to see improved methodologies, packaging tools, and end-user
empowerment announced alongside it.

Hats off to folks like Nir Sofer and Mark Russinovich who've shown the world
just how much you can pack into a small, single-file, zero-installation EXE
that just runs when you click it.

I've been using the same computer for 10 years now (with upgrades to
components like video, RAID controller, SSD's) and have over 700 programs
installed on it. I use third party monitoring software [1] to capture a disk
and registry snapshot before and after any installation (and often on
updates). The machine is still nearly as snappy as the day it was built (yes,
I benchmark!), but it's taken a LOT of ongoing work to keep it that way. I use
other tricks, like locking down certain registry keys and folder locations
which programs like to pollute (or where that causes breakage, using startup
scripts to clean them out after the fact in a cat and mouse game). One big win
was completely giving up on My Documents. I treat it like just another
AppData, and organize the content I really care about elsewhere.

All that said, I really like that my Windows software still comes directly
from the vendors. I'm not sure how I feel about distribution becoming more
centralized under Microsoft's control. Part of me hopes to see a vibrant
ecosystem of third-party repos emerge, while another part dreads the confusion
about where to get a package that may entail.

I do have to give Microsoft credit for enabling third party tools to take care
of some of the shortfalls they haven't. On more locked down platforms that's
been more difficult.

[1] [https://www.martau.com/](https://www.martau.com/)

~~~
contextfree
UWP and MSIX are/were intended to address the problems you mention

------
tjoff
Do you need a microsoft/whatever account for this? I can't see anything about
it but wouldn't be surprised if they forgot to mention it...

------
jamieweb
I'm interested to know whether the SHA256 hashes are just done on a TOFU
basis, or whether they actually verify the Authenticode/GPG signatures of the
EXE files to get an 'authoritative' or 'trusted' hash.

------
sigsergv
What about uninstalling apps?

------
Ari_Ugwu
Maybe the most exciting thing I've heard so far from Build 2020.

Getting Closer to my dream install:

* WSL 2

* VS Code

* .NET 5

* Windows Terminal

* Package Manager

* Edge

All that's missing is Edge on Linux and letting me write cross platform apps
that use edge as a (headless) common runtime.

~~~
eat_veggies
Given that edge is just chromium now, I'm curious as to how an edge headless
runtime would differ from node or electron

------
akandiah
Is this an msi hiding in a wrapper? Anyone who has dealt with the innards of
an msi file knows it's a dog's breakfast!

------
wronex
Are they doing any form of caching (think CDN) to battle link rot?

