customize the extensions gallery

[daiyam]

Description

This PR allows the user to customize the extensions gallery.

With environment variables:

• VSCODE_GALLERY_SERVICE_URL
• VSCODE_GALLERY_CACHE_URL
• VSCODE_GALLERY_ITEM_URL
• VSCODE_GALLERY_CONTROL_URL
• VSCODE_GALLERY_RECOMMENDATIONS_URL

Or, with a custom product.json located here:

• Windows: %USER%\AppData\Roaming\VSCodium
• macOS: ~/Library/Application Support/VSCodium
• Linux: ~/.config/VSCodium

Issues fixed

• Switching between marketplaces #519

[GitMensch]

That's nearly perfect. As previously pointed out in #537: please use VSCODE prefix for environment variables (VSCODE_GALLERY_SERVICE_URL and similar).
I'd say this PR can be merged then.
I'm not sure if this will work but can you please adjust the text to say "resolves #519" to link it?

The only other missing piece for making the PR perfect is the adjustment of DOCS.md mentioning the option of defining either the environment variables or the per-user product.json (with a note "be aware that this possibly means you manually have to update it each time when VSCodium is updated").

[GitMensch]

That's very good to go. @stripedpajamas can you please link #519 and then merge this?

[AntonOks]

Or, with a custom product.json located here:

* Windows: `%USER%\AppData\Roaming\VSCodium`

* macOS: `~/Library/Application Support/VSCodium`

* Linux: `~/.config/VSCodium`

Could you please also add the vscodebinary path into that "lacation search" as the last option?

Something like the GetModuleFileName?

For me, this would be great because I use SCOOP and would then just persist the product.json in the manifest. And I'm pretty sure there is more "portable" use cases, which would appreciate this;)

[GitMensch]

@AntonOks Wouldn't it work to persist the default product.json? Or use the general more portable version to create a wrapper for the vscode binary (possibly you need one in any case, I don't know) and there check for a vscode.env or similar file, if it exists take every line and set/export it before starting the binary. This way you can setup the environment variables you want to tweak (like the marketplace URL) and don't need to update other parts of product.json manually after an update.

[AntonOks]

@AntonOks Wouldn't it work to persist the default product.json? Or use the general more portable version to create a wrapper for the vscode binary (possibly you need one in any case, I don't know) and there check for a vscode.env or similar file, if it exists take every line and set/export it before starting the binary. This way you can setup the environment variables you want to tweak (like the marketplace URL) and don't need to update other parts of product.json manually after an update.

Well, yes, in my use case and as SCOOP is very flexible, everything is possible ;)

Maybe I misunderstood your comment with a custom product.json located here then... I tough it's about having an additional / separate product.json somewhere and the config/settings there would "overwrite" whatever was set in any general / global product.json before. As next the "environment vars" and finally command line options should have precedence... GIT with it's very flexible approach was in my mind.... see git config --list --show-origin...

Anyhow, maybe I'm just on the wrong path here && anyhow, your pull will help a LOT. Thanks for doing this!

[GitMensch]

I tough it's about having an additional / separate product.json somewhere and the config/settings there would "overwrite" whatever was set in any general / global product.json before

No, that's not how it works, this would need much more things to change and a patch like this wouldn't be reasonable for vscodium. Personally I would recommend against a personal product.json, the only reason to have it in is because so many people requested it and actually it is not a big thing to patch.
I definitely recommend the environment variables, that is definitely a reasonable thing and if this works fine I'll add a PR (or let someone else do that) against the vscode repo. As enterprise environments actually did request it they may accept it and if not, well vscode is the alternative in any case :-)

[AntonOks]

@AntonOks Wouldn't it work to persist the default product.json?

Sure, I could. But as soon as a future VSCodium release introduce new config options, or change other important settings beside the "gallery", we would be lost in space :|

That's why I thought having a product.json close to the binary with a specific to this installation/binary config for a sub-set of the options would be great and the topic here...

[GitMensch]

That's why I thought having a product.json close to the binary with a specific to this installation/binary config for a sub-set of the options would be great and the topic here...

I understand that. Feel free to open an issue in the main vscode repo and/or provide a PR request there (but I personally don't think it will be ever done, the environment variables seem possible though).

[daiyam]

I tough it's about having an additional / separate product.json somewhere and the config/settings there would "overwrite" whatever was set in any general / global product.json before.

Sorry @GitMensch but it's exactly what it does. The merge between both product.json isn't limited to the gallery options. I don't see any problem to that but it's up to the user to not break things and to up to date. More choice is good.

[daiyam]

@AntonOks Can the installer just copy the file into user's config directory?
The persist command is used to save up files, which are in the binary folder of the app, so that updates don't overwrite them. There is no real benefit compared to put it in the user's config directory.

[GitMensch]

@daiyam Thanks for pointing that out, just rechecked the code and yes, that's what it does.
This is quite cool. And because of the merge there's no need for a warning.

[AntonOks]

@daiyam

Can the installer just copy the file into user's config directory?

Sure, SCOOP can do whatever PowerShell can... and much more, but that's not my point. It's about having more flexibility at all. So i.e. one could have some VSCodium installations in parallel with the same user and the same system or container, still with different settings, say CI/CD, debugging, testing, ....

The persist command is used to save up files, which are in the binary folder of the app, so that updates don't overwrite them.

Half-way-true. persist can keep also files or directories withing the apps tree, see

• https://github.com/ScoopInstaller/Main/blob/b44cb03f0a52043ba921f29764eba9581db727dc/bucket/cmder.json#L23
• https://github.com/ScoopInstaller/Main/blob/ae73ced2600a17e42305e90f55a08cceab3112f1/bucket/inadyn-mt.json#L30
• https://github.com/ScoopInstaller/Main/blob/5dbcb857faf50e464e6d2e2246b9e2911b46fed4/bucket/tor.json#L40

There is no real benefit compared to put it in the user's config directory.

Disagree here, see above.
And also in general if you think "portable mode", an application should never depend on Registry settings, environment varables or a "user home" at all, right?!

[daiyam]

There is no real benefit compared to put it in the user's config directory.

It was in the context of the persist command for VSCodium (since the app doesn't put config files into the installation directory).

For the portable mode, options are:

• use the argument user-data-dir
• use powershell script to setup the environment variables before launching vscodium $env:VSCODE_GALLERY_SERVICE_URL = 'http://'

[stripedpajamas]

Looks amazing

[stripedpajamas]

Thank you @daiyam for finishing up this idea/implementation. I think a lot of people will be happy with this 😄

[GitMensch]

@daiyam How do you feel about doing a PR for the partial product.json in the vscode repo? If that is accepted then MS would document more for us and we can reduce the amount of patching.

[daiyam]

@GitMensch I didn't have much success with PR on vscode repo (1 for folding, still open after 3 years; 1 for alphabetically ordering the tabs, closed for being "out-of-scope"). So I don't think I'm going to have much chance to have that PR to be merged. But feel free to try ;)

[GitMensch]

@daiyam: how can I "unset" something via the user json?
I have a scenario where the auto-update and its check must be completely disabled, this is currently achieved by deleting the

	"updateUrl": "https://vscodium.now.sh",

entry from the installed product.json after install.
Can you please add something like

	"updateUrl": None,

to remove a setting during read-in and preventing it to get merged from the main one (or set it that way and pre-process the list to remove the entries with "None")?

[daiyam]

Have you tried "updateUrl": "",?

[GitMensch]

Have you tried "updateUrl": "",?

That was my first approach but using that "Check for new version" is still available; if I remove the line from the installed product.json then that menu entry is not shown any more.

Maybe I did something wrong? Does it work on your side?

Note: the entry in the docs is wrong, for Win32 the default path is %APPDATA%\VSCodium; or, if it is set via command line, the user-data-dir setting + VSCodium as seen in microsoft/vscode@088d4fb.

[daiyam]

%USER%\AppData\Roaming = %APPDATA% 😉

No, I haven't tried. product.json is read from 2 different places. Maybe updateUrl is read from the place I haven't patch (in main.js).

[daiyam]

@GitMensch When doing the patch for 1.55, I found that product.ts can't access the argument user-data-dir. The issue is that file product.ts is also used in the web version of VSCode. So the use of the variable process or any global variables from node aren't allowed.

[GitMensch]

Hm, I may was too fast on user-data-dir or have looked at the wrong VSCode source.
That leaves the environment variables in the docs - fixed that with #691 - and the search for the way to disable the update via user-defined variable.

Note: vscode applied some changes shortly before the 1.55 release and @daiyam fixed the necessary import in d8a91cf:

-const { getDefaultUserDataPath } = require('./vs/base/node/userDataPath');
+const { getUserDataPath } = require('./vs/platform/environment/node/userDataPath');

And the function function is now actually defined in vs/platform/environment/node/userDataPath.js.

This would make even more variables (first environment VSCODE_PORTABLE, then cli-option user-data-dir, then environment VSCODE_APPDATA) apply before the OS specific one. More options to document?

[GitMensch]

%USER%\AppData\Roaming = %APPDATA% 😉

No. That would be %USERPROFILE%\AppData\Roaming.

[Rohaq]

On Windows:
I've tried creating a product.json under %APPDATA%/Roaming/VSCodium as specified, with the edit suggested for using the MS marketplace - but VSCodium doesn't seem to be picking up these changes up.

Works fine after setting user environment variables though, at least! 👍🏼

[assange0]

On Windows:
I've tried creating a product.json under %APPDATA%/Roaming/VSCodium as specified, with the edit suggested for using the MS marketplace - but VSCodium doesn't seem to be picking up these changes up.

Works fine after setting user environment variables though, at least! 👍🏼

Same as you, product.json under %USERPROFILE%\AppData\Roaming\VSCodium doesn`t work.

[bylmzio]

%USERPROFILE%\AppData\Roaming\VSCodium

Anything new?
Same here

[quinncomendant]

A quick note to help new users of this feature: the custom product.json file placed into, e.g., ~/Library/Application Support/VSCodium, is merged with the original product.json file, so it is not necessary to copy the entire file and then modify (in fact, copying the entire file will result in errors when the installed vscodium internal file hashes get out of sync with those specified in the custom product.json file).

To use Microsoft's extension gallery, your custom product.json file only needs to contain:

{
  "extensionsGallery": {
    "serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
    "cacheUrl": "https://vscode.blob.core.windows.net/gallery/index",
    "itemUrl": "https://marketplace.visualstudio.com/items"
  }
}