hi all, thanks for the interest/comments; I decided to write-up a page that details this on the docs.

http://inedo.com/support/documentation/proget/feeds/other-types

I'm hoping we can use this public thread to maintain the discussion on technical detail; otherwise it'll get stuck in my email, or somewhere else, and we can get everyone to chime in this way.

That said, @M-W if you've got any insight into how R/CRAN works please do share :)

Of course, plan versioning is introduced in a later version, and Rafts (which allow for Git-based storage) is coming in 6.2.

I definitely understand the hesitance to upgrade, but worth noting ---- for once 6.2 comes around we'll offer some great migration tactics to let you pull applications from really old versions of BuildMaster. We'll also better support multi-instances of BuildMaster, so each group can upgrade as they'd like.

That said, the Plans database table will contain your OtterScript plans. Not sure if that's a good solution, but pulling from that table will give you latest versions.

Hello;

There may have been a miscommunication somewhere; do you know specifically what you were told?

We recently added the Feeds Management API, but that's only to manage feeds (not packages).

I just updated the documentation, and it will be published soon.

You can delete (permanently remove) or unlist (hide from most search results) NuGet packages from your feed by navigating to the package page and clicking the corresponding Delete Package or Unlist Package button. These actions require the Feeds_DeletePackage or Feeds_UnlistPackage permission attribute, respectively.

To programmatically delete a package from your feed, you can use the NuGet CLI's delete command, or make a DELETE request via HTTP:

DELETE http://{proget-server}/nuget/{feed-name}/package/{ID}/{VERSION}`

Note that this behavior is different than NuGet.org's DELETE command, which unlists packages instead.

To programmatically unlist (or relist) a package, you can use the NuGetPackagesV2_SetListed method within the Native API.

Is that helpful?

Definitely sounds like a bug; we've get it logged.

By the way, we've got some real exciting container/registry features coming very soon in ProGet 5.3. Stay tuned!

Hi @jeff-miles_5073 ,

Thanks for the first inquiry; I just updated the documentation! These must be "relatively new", and I know we've had a few customers using universal packages for this.

We have some Terraform integrations on our roadmap for 2023, so this definitely something we'll look into on our own as well.

Cheers,
Alex

Just as an update, we will be doing this:

https://inedo.myjetbrains.com/youtrack/issue/PG-1555

"Proxy npm audit requests to npmjs.org (experimental)"

Hi @shfunke_1795 , @jrottmann_6111

Thanks, I just added this to our documentation page!

I didn't look too deeply, but I found some initial documentation:
https://wiki.alpinelinux.org/wiki/Package_management

It seems this is "like Yum/RPM but for Alpine Linux"? None of us here use Alpine Linux, so there's a pretty big learning curve to get started. Any help here would be appreciated, and definitely move this along :)

Is this related to "APK" that Android uses?

Is the "API" mostly like basic file downloads, based on an index file? Are you able to "hack" or do a PoC using ProGet Asset Directories?

Hi @tkolb_7784

I wanted to provide an official answer to this:

Are there plans for (easy) HTTPS support in the internal webserver? Applying a self hosted certificate and deploying it to all build servers and developer machines seems over the top for me right now.

Yes. Not exactly sure how yet, but we would like the integrated webserver to support this as easily as possible.

@shayde @sebastian really appreciate the help, we'll get this incorporated ASAP !!

Thanks for clarifying @sebastian

So I'm not exactly thrilled by this UI, but maybe this is fine.

What do you think?

This is a kind of "quick and dirty" page that would show up if you clicked on that GPL-2.0 license and the "# projects" number.

Here's one for the packages as well:

Hi @kichikawa_2913 @jeff-miles_5073 @martin-helgesen_8100 ,

Good news! We've got a Terraform Feed working on version 2024.20-rc.4 and it seems ready for release:

I'd love to get a second set of eyes on our approach and the docs; this was a really interesting protocol/API to work with because there are no "Terraform Packages" - basically everything is just a pointer to a GitHub repository.

So, ProGet just packages it in a universal package and the Terraform CLI seems to be happy. What's a little unfortunate is that the hostname/feed need to be in the package, but that's also how Docker works. So I guess it can't be helped.

Thanks,
Alex

Hi @zs-dahe ,

The Package Promotion API only be checks for permission against toFeed - you don't need any other permission on the toFeed or fromFeed.

As far as more granular permissions, perhaps setting up a Personal Key for like a builds user would do the trick? That'll let you reuse the API Key and set up very granular permissions.

We decided not to duplicate that granular permission setting in the API Keys because it's already confusing enough

Thanks,
Alex

Thanks for clarifying @matt-lowe!

some IT managers are very much stuck on the 'Microsoft' rut and are unable to see past it, no matter the cost and time it adds to most IT management
...
TBH the only way I managed to get ProGet installed was for managing PowerShell scripts for a small project and have managed to keep it ticking over with other options.

I've definitely heard that... personally I think this is where vendor/sales can really come in and make a difference.

Sometimes it's a lot harder to sell things internally... it's not so much about "giving a sales pitch" but more that decision makers can have a different relationship with sales execs.

It's one thing to blow off a vendor demo or delay a project... but team morale can get shot if you do that internally, so it's safer to stick to status quo. And of course, sales execs can challenge the status quo in a much more direct way... trying that as an employee might be uncomfortable or feel insubordinate.

Anyway this isn't related to WinGet, but we might be able to help with the bigger picture -- might be worth spending 15-20 minutes just talking through it and seeing if there's any paths to go from there. We're seeing a lot of movement on the WinOps/ProGet/Chocolatey in big orgs, so clearly they're getting something over DIY solutions or WinGet.

Feel free to shoot a note at the contact form, and we'll take it from there!

Hi @matt-lowe

You're the first person to ask about it in three years. I kinda forget it's a thing :)

So since then, feeds are a lot easier to build.. but I also don't want to implement the next Bower feed

I don't remember much interest in WinGet from our WinOps userbase... and I only occasionally see mention of it on Twitter𝕏. I think Chocolatey has a lot more traction and I get the impression that it's more capable, stable, and mature. And it's very well supported.

What's your impression? Have you been using it? What's better about WinGet over Chocolatey?

I think this somewhat recent Reddit comment captures the general sentiments about Microsoft projects like WinGet:

AFAIK, winget was/is a Microsoft led attempt to offer something instead of everyone using chocolately. Sadly though, it's not a replacement.
 
That is, Microsoft has an "answer", but not necessarily commitment behind winget. So, unknown how well packages sitting behind winget will be maintained. And historically, it has been under scrutiny. Is it good now? Not sure anyone can ever say for sure.
 
Now, there will be those that say "fixed", today's winget isn't like the absolute mess it was early on. And that might be true. But how would we (the customer) know? Again, biggest problem with Microsoft is the "not knowing". Or the "deception" of making a project look "better" and then realizing it was all just a ruse.
 
Up to you. Today's weather report, winget is "good". But can't really say anything about tomorrow. Oh, and thank you Microsoft for making yet another ambiguous thing (not handling its delivery, deployment or long term outlook well).

The fact that their package repository is just stupidly large GitHub repo maintained with pull requests is concerning. The discussion with @sylvain-martel_3976 above - I think they were just considering WinGet, and didn't use it yet. Not sure what ever happened with that.

Anyway let me know your thoughts!

Alex

@davidroberts63 check out 2024.14... added via PG-2783 :)

Also, on the builds page, I'd recommend having a sort and/or filter ability for the Stage.

Oh yes, I could see that helping... actually i'm not sure if it's even listed on the Build page. How many active builds do you have BTW?

@carl-westman_8110 very happy to hear it, thanks for the kind words :)

@carl-westman_8110 it's definitely a nifty and convenient function, but a poor feature from a product standpoint.

Users don't expect functionality to bundle content like this, so they won't use it unless we push it -- and to do that, we need to articulate benefits, show how it's a better solution than what they're doing now, and convince them to take the time to switch.

That's obviously a lot of work, on top of all the code to get it working.

I know a handful of users have found some value in virtual packages (and we use it internally), but being reminded about them now -- with about a decade more of experience behind me -- it feels like the wrong thing to focus on at the time, with limited resources.

That said, it doesn't even come close my top 10 worst product choices... so probably better we built that, than something else

Alex

Hi @carl-westman_8110 ,

It's a Virtual Package; they're kind of a niche solution that, in retrospect, we probably shouldn't have created them.

Alex

Thanks for clarifying @sebastian

So I'm not exactly thrilled by this UI, but maybe this is fine.

What do you think?

This is a kind of "quick and dirty" page that would show up if you clicked on that GPL-2.0 license and the "# projects" number.

Here's one for the packages as well:

Hi @stuart-houston_1512 ,

If you're using almost entirely libraries that are available on PyPI.org and Anacaond.org, that makes the most sense. Users probably won't notice much of a difference.

Once libraries start being pulled through ProGet, you can start setting up policies/compliance rules to restrict packages. Or at least get warned about them.

At some point you can set up a package approval workflow, but I usually don't recommend that from "day one" - it's a bit too restrictive for end users, who are used to any package, any time.

If it's easy for you to identify first-party packages (maybe they are prefixed with MyCorp or something), then you can bring those in with bulk import. If no one uses (downloads) them after while, you can delete them with retention policies.

Cheers,
Alex