Import / Export feature

[Demitrius Nelon (denelon)]

Hello everybody,

We're working on the import / export feature for the package manager. I wanted to share what we're thinking for the JSON schema.

The package manager will be able to export the list of packages that have been installed from a known source, and subsequently "import" the list of packages onto another machine.

[Thomas Lee (doctordns)]

A good start. Thanks.

[Thomas Lee (doctordns)]

So some comments:

1. Winget version - I assume you want a semantic version rather than 'just' a string? I am not regex expertise, but is the pattern just that? And in the description for this item, It might be nice to mention that it is a semantic version. Also, which file is 'this file'?
2. creation date - which is "this list"
3. Under sources\items\properties - make source details mandatory. Specifically, state the URL (etc) where this came from. Experience with PSGallery suggests the more you can make required, the better the effective documentation will be.
4. Arguments are going to need string replacements? Not sure a simple string handles that. you might want variables to follow a switch so as to customise the installation
5. There seems to be no variables that an installation might want to make use of (c/f Azure templates)
6. Type - there needs to be a constrained list of package item types.
7. Channel - again a constrained list of applicable channel
8. Should there be somewhere that defines where the application should be installed?
9. Should there be a sign that a package is installed for one user or all users?
10. What about a list of groups that may install a package?>
11. Should there be some indication that admin rights are required to install the package?

A good start. AND a good start on an object model for eventual PowerShell use.

[Demitrius Nelon (denelon)]

Thomas Lee (@doctordns)

Thank you! These are great comments.

1. We're currently working through some challenges with the MSFT versioning format that generally contains 4 positions to signify versions. I will see what we can do to ensure consistent formatting with respect to semantic versioning. Our intention is to maintain semantic versioning for the package manager to the extent we can.
2. The intent here is to identify when an export was generated. There are packages that may evolve over time, and this value might help identify possible issues.
3. I'll look into this a bit more.
4. Can you provide an example of what you're thinking here?
5. We wanted to get the import/export out quickly so we can iterate. We don't have dependencies, or pin implemented yet, and those will likely have an impact on import/export behavior in the future.
6. I think we will likely generate an enumeration for each key we can. This "type" is a great candidate.
7. We have been challenged with creating an enumeration for channel. "Release, GA", "Beta, Preview", "Alpha, Daily" are all candidates we've thought of, but we assume there may be many more. This one has been relatively hard to constrain.
8. As this is the first iteration, we were essentially looking to keep installer defaults and not try to override, but we do see value in additional customizations.
9. We'll look to see how consistently we can identify user vs. system installations. We haven't implemented that set of behaviors yet either. It's coming in the new manifest specification we're preparing to share.
10. Can you provide an example for this one?
11. That ties back into User vs. System. We're adding metadata to the new manifest spec to help with this specific issue.

More goodness coming soon with the 1.0 manifest schema draft, and shortly thereafter, the REST API swagger documentation.

[MisinformedDNA]

Demitrius Nelon (@denelon) Are overrides being tracked anywhere? I'd love to see that.

[Demitrius Nelon (denelon)]

MisinformedDNA I just did a quick check, and didn't see any Features mentioning overrides for "Import"/"Export". Feel free to create an issue. I'd like to see your thoughts on whether it's just something we add to the schema so when you run import, they can get executed, or if you have thoughts on how to capture them in "export". That's an interesting scenario.

[MisinformedDNA]

Done. #1512

[Thomas Lee (doctordns)]

Re 1. Good luck with that! :-)
In the mean time, can you do a regex that uses an OR so version is either a Semantic version of a MS 4-place version?

Re 2.
Perhaps explain that in the description? ANd note which file 'this' refers to explicitly?

Re 4.
Suppose the normal installer would do something like this:

installer.exe /blah1 foo.bar  /s myuser.txt /o c:\foo\bar\
``
In PowerShell, this might look sort of like
installer.exe /blah1 $input1 /s $input2 /o $output1

With azure templates you have variables ($input1, etc) that are substituted at run time.

Re 10
Suppose I have a tool for DNS (DNSTools.Exe) and I only want members of the DNSAdmins group to be able to install it?

[Quang Kieu (quangkieu)]

Re 10
I think this feature kind of when winget more mature as that is kind of similar to GPO policy.
When initial import/export finished, you can work and by just edit to different lists and send to different computer group

[Thomas Lee (doctordns)]

Is that easily scriptable? Not sure?
Any thing that requires hand editing is error prone.

[Chaphasilor]

I'm wondering which programs will be exported? Anything that was installed through winget? Anything that can be installed through winget? Given that some commands (like the experimental uninstall) can work with all ARP programs, I believe this distinction should be made.

Also, will we be able to pick items to import/export manually? Maybe export/import everything by default, but add a flag/switch that allows us to unselect certain items.
(I just saw that app lists will be used for that, but maybe this should be added on top? At least when importing, it could be useful to exclude some apps if needed...)

[Demitrius Nelon (denelon)]

We're looking to be able to export anything that has a corresponding package in the available sources. We plan on having a switch to specify export for a single source.

Yes, that does mean if it is found in ARP and there is a corresponding package in one of the available sources it would be exported regardless of how it was installed.

Initially, you would need to remove the packages you don't want imported from the .json file.

[Chaphasilor]

That sounds good!

Matching package in ARP probably means matching version as well, right?

[Demitrius Nelon (denelon)]

Easier said than done, but yes, we're working towards that as the goal.

[Demitrius Nelon (denelon)]

We're about to make "import" a stable feature that doesn't require the experimental setting.

Several additional features came up in this thread. Please make a new issue for each one. The smaller they are, the faster we can implement them. If they have lots of 👍 that moves them up in priority.

We do support versions in the file with the --include-versions argument in winget export.
We also support multiple sources with export.
If the users machine does not have the corresponding source, those packages are excluded.

[Demitrius Nelon (denelon)]

Export is still very lacking in terms of matching ARP entries with manifests in the winget default source or the msstore experimental source. We're still enhancing that logic before we release export as stable. It also has the prerequisite of winget list being released as a stable feature.

[Alexandre Nédélec (TechWatching)]

Import is great, however it does not work when some packages names could correspond to multiple packages.
For instance I got an error when trying to import a json file with Microsoft.Office and Microsoft.Teams because "mutiple packages could map these criteria".

[Demitrius Nelon (denelon)]

Alexandre Nédélec (@TechWatching), that's a bug 🙁. Please submit a Bug Report. We would also appreciate if you would submit feedback ([Windows]+[f] - Category "Apps" & "Windows Package Manager") so we can look at the logs. It also helps if you share the link to the feedback in the bug.

[Alexandre Nédélec (TechWatching)]

Thanks, here it is: #983