[ProGet] Feature Request: Visual Studio Code - private Extension Gallery

sebastian.lieschke_5424 · 5 Jan 2024, 13:18

Hello inedo-Team,

as we're using heavily ProGet for development we also use heavily VS Codium.
Therefore we would like to be able to use our own private Extension Gallery to make use of the wonderful possibilites given by extensions. Also we want to be able to use our own-developed Extensions more intense across our teams.
At the moment we have to make it "the manual way" for internal usage of extensions: download vsix, upload to an internal vsix-feed on proget and then the developers have to download it from there again and install it manually.
It would be absolutely awesome to be able to use proget as an internal gallery for our vs code using developers but we couldn't figure out how.
We would like to set our own gallery as described here: https://github.com/VSCodium/vscodium/blob/master/docs/index.md#how-to-use-a-different-extension-gallery
Unfortunately proget-vsix-feeds seem to not provide the required endpoints (or we didn't find out how :) )
Could you please add that feature or provide a guide how to set up?

Thanks!
Sebastian

apxltd · 6 Jan 2024, 01:15

Hi @sebastian-lieschke_5424 ,

Thanks for the request; this is something that is close to requesting a new feed type, so I'll use that rubric to decide.

As we wrote in that link, new feeds can be very time-consuming to research, develop, document, maintain, etc. Like with all software, even estimating the cost is costly - so we can't really even begin the initial research until there's sufficient demand or market opportunity to justify the possible investment.

To be honest, I don't see there being much demand or any market opportunity for this. Time will tell, and maybe someone will comment on this in the future. But for now this seems really niche.

That being said - I took a quick look at the document you linked, and I don't see API docs (i.e. those missing endpoints you mentioned). Maybe it's something as simple as a basic JSON document. Maybe it's an absurdly complex and undocumented API.

However, if you can figure how the API works, and it turns out to be something like a simple JSON/XML index file.... and you can prototype/fake that using a static file inside of a ProGet Asset Directory... then we can likely implement that quite easily.

I know that's how RPM and Helm Chart feeds got started long ago :)

Alex

dimas

I am currently looking into hosting my own internal vscode extensions gallery. Openvsx is pretty much the only viable candidate, but it requires spawning multiple docker containers with relatively large compute and ram requirements for my small 15 person team that probably only updates our airgapped vscode once a month.

There is actually a documentation on how to host a vsix feed for vscode on proget, but after a quick test it can't differentiate builds for different architectures.

For example, the python extension has different builds for different archs. Uploading them only results in a single entry on the proget vsix feed.

apxltd

Hi @dimas ,

It looks like VSCode still doesn't support private galleries. I know users have been requesting it for over eight years now.... so maybe it'll come soon! But until then, we can't implement it in ProGet.

I'm not sure what you mean about the python extension... but I do know that a visx file uses some kind of GUID to uniquely identify an extension. If the different "versions" of python visx use that same ID/Version, then I suppose it would get overwritten.

Alex

dimas

@apxltd The extension actually have several builds for different platforms. You can download them using these links.

However, the ProGet VSIX feed doesn't distinguish between these builds. The only way to solve this problem was to create a separate feed for each platforms.

apxltd

Hey @dimas ,

Ah, that makes sense. Looking at the manifest files, they have the same Identity@Id (which is what ProGet uses for the Package Name) but a different Identity@TargetPlatform (which must be new-ish):

<Identity Language="en-US" Id="python" Version="2025.2.0" Publisher="ms-python" TargetPlatform="win32-x64"/>
<Identity Language="en-US" Id="python" Version="2025.2.0" Publisher="ms-python" TargetPlatform="linux-x64"/>

We could probably figure something out in ProGet, but it's not trivial when it comes time to changing how we identify Package Names.

Can you try editing the manfiest file inside the vsix archive, and seeing if that works for your use case?

So basically:

<Identity Language="en-US" Id="python-win32-x64" Version="2025.2.0" Publisher="ms-python" TargetPlatform="win32-x64"/>
<Identity Language="en-US" Id="python-linux-x64" Version="2025.2.0" Publisher="ms-python" TargetPlatform="linux-x64"/>

Not quite sure if that would work, but figure it's worth a try.

Thanks,
Alex