Support Paket for dotnet project

[vbshift]

Do you plan to support Paket for dotnet project ?

Thank

[greysteil]

Yes! It's not on our immediate roadmap, but we definitely want to add support in future. I'm going to keep this open so others can watch it for updates, and add their voice to adding support.

[haf]

Since paket is a more mature way of handling dependencies for .net projects, having dependabot read paket.lock from the root would be really great!

[tforkmann]

Any news on that?

[jurre]

We've paused accepting new ecosystems into dependabot-core for now, we've described some of our reasoning here: https://github.com/dependabot/dependabot-core/blob/main/CONTRIBUTING.md#contributing-new-ecosystems. So this is not something that will land in the near future unfortunately.

[cdrnet]

Paket is not really a separate ecosystem, it's really NuGet and NuGet packages - it's just a different client and different files that need to be updated. Thanks to the explicit solution level lock files, the implementation could even be simpler for Paket than with raw nuget, for both monitoring and pull requests.

[CumpsD]

Sad to see only half of an ecosystem is supported. This is not about adding a new one, but making the .NET one more mature.

[da9l]

@infin8x @jurre I think most of the F# and paket using participants in this discussion would argue that this ticket is incorrectly tagged. Since paket is part of the .net ecosystem this is not a feature request nor a new-ecosystem request. It should really be a bugreport or improvement on the .net ecosystem support in dependabot since it is lacking support for half of the tooling for .net dependency management (paket).

This is in line with the reasoning you are linking to above:

"we want to focus more of our resources on merging improvements to the ecosystems we already support."

Dependabot is already supporting .net and this is an improvement to the .net ecosystem support that will be in line with:

"We aim to provide the best user experience possible for each of these..."

[tknightnd]

Incorporating Paket into dependency checking would be a fantastic step forward in supporting the .Net ecosystem, and I must agree with @da9l that this is not a request for new ecosystem support, but rather a step towards completion.

Paket is perfectly usable with C# project types: it is not exclusively for F# projects at all. Even nuget.org supports Paket, before Cake. I suspect it's not seeing wider use because its documentation has F# all over it.

Please reconsider, and if you need help I'm sure there's a small army willing and able.

[alexeyshockov]

Very sad to see that Paket is still no supported, and there are no even plans to support that.

.NET Core (*.csproj) dependency management is complicated, broken in some places and is not fully supported by Dependabot anyway, so Paket would make a lot of sense, since it's simpler and work like NPM, Composer for PHP and other tools, so definitely easier to support.

And it's definitely not a new ecosystem!

[kncesarini]

Here's one more vote for this. Crucial for MANY dotnet projects.

[jeffdoolittle]

Same here. Paket solves a lot of issues with dependency management and we need dependabot support for it asap.

[tforkmann]

Same!

[ImaginaryDevelopment]

Closing #1738 potentially removed the direct link from the issue to #1944 which I would think lowers the chance someone picks up that PR and pulls it over the finish line. So if anyone is looking for a PR to assist with on this issue, that may be it.

[exvuma]

Hi folks, I recently joined the Dependabot team as a product manager 👋🏻. Just wanted to let you know though we don't have a hard timeline for adding support for Paket right now, we are listening! We're actively working on easing the general path to adding ecosystem support, and I'm hopeful we can loop back soon with the next steps and timelines.

[ImaginaryDevelopment]

We're holding off the possibility of rolling our own automated scanner for our repos. Almost 2 months later, any progress update for us? @exvuma

[jeffdoolittle]

Hi @exvuma - any updates on this for us?

[BlythMeister]

Still no updates?

The dependabot alerts for .net and npm via GitHub has been so useful, it's a shame that half our repos do not alert as they use paket.

[64J0]

Still waiting for paket to be supported 🚀

[voronoipotato]

Agreed, it would be helpful!

[bremerg-accuity]

@jonjanego - is there any news on adding support for Paket? We have a quite a few repos that use Paket and the lack of support in Dependabot is increasingly painful. Thanks!

[brettfo]

@bremerg-accuity I'm the team that owns the NuGet updater.

The short version is that we don't currently have the bandwidth to enable and support the Paket updater and merging a "good enough" updater for paket could quickly fall apart, and enabling a non-complete updater can feel worse than not having an updater at all. We're focusing our efforts on making the csproj/vbproj/fsproj scenarios as solid as we can. I'll leave this issue open, however, for future tracking.

Adding a new file type to the updater (paket.lock) isn't necessarily trivial, and while the code path would likely be something like this...

if file_exists('paket.lock')
  # go down the paket path
else
  # use regular dotnet/nuget updater
end

...there are numerous places that would need to happen and there are some complicated interplays between dependabot and an individual updater where the updater is asked what packages currently exist, what updates are possible, and actually performing the updates.

I used to work on the F# compiler and language services and have some familiarity with Paket and interestingly enough, I was recently dealing with an issue with Artifactory/JFrog NuGet feeds and found that Paket doesn't support those, but I left a comment detailing how I worked around it in this repo in the hopes that the Paket maintainers would be able to use my findings.