I’ll think about it. Perhaps some of the stuff that came up for nugettrends could be valueable more broadly and we could discuss and I could contribute
thankss
It was not quite the same as past years 😪
If you have cool ideas that would make sense on NuGet.org you should consider pitching an idea on NuGetGallery and we could talk it through.
Give us full access to the Gallery data, then we can build stuff 😀
About download counts, could we use the JSON file instead of hitting search endpoint?
Or may we 😀
And for opening up gallery data, make a proposal! remember my team has to work within Microsoft accessibility security privacy and availability standards etc
I think the one missing piece for opening up the downloads file in my mind is figuring out how to remove deleted package IDs. There's also some package IDs in that data file that never existed due to a bug and may contain internal package IDs. But honestly in my mind it's pretty close to just opening up. I would need to get my leadership on board though
I’d love to see more public statistic APIs come out of that work
@loic-sharma @joelverhagen regarding reverse dependencies and optimizing for querying. Since dependencies are expressed as version ranges, should one a) create a row for each possible version in the range that matches or b) just create one row for the lower bound of the version range. NuGet resolves with the lowest dependency by default, and this is also how NuGet gallery works when clicking a dependency.
I think that depends on the desires user experience. In my opinion it's pretty costly and not very useful to have a list of all versions in that range. Depending on the graph or typical project some of these versions may never be selected in practice... Plus this list will grow over time approaching the list of all versions since most people put just the min bound in their dependency version range.
For a UI that shows reverse dependencies, it might just be enough to have [parent id, version] -> [dependency id] as the edge you derive from a nuspec/catalog leaf and build specific documents from that. How useful really is TFM and version range for UI purposes. Needs thought.
@mholo65 ^ since I don't know how notifications work here
The simplest data structure is [parent id] -> [dependency id] but as we know packages pick up and drop dependencies over time so that one's too simple and loses a lot of value. I'm thinking just one step more complex than that.
Like maybe only track the information for the latest version of a package. Hm... Still thinking
I'd just like to keep it as simple as possible for the initial implementation
TFM is good to know as lot's of maintainers are looking into dropping
net45 etc and just do ns2.0... Som might even want to go ns2.1 or netcoreapp3.1 in order to use some features... Multi-targeting comes with a cost, if possible people want to drop it..
Version doesn't really matter, all I want to know is if they are using latest or not.
I see, so reverse dependencies TFM is a proxy for TFM adoption. I say proxy because the real indicator is how it's being consumed in shipping products not necessarily libraries. Other library authors are likely operating on the same information as you ( which is very little information... Nuget.org doesn't give any help so far...).
Er, maybe not "shipping products" but volume of package consumers TFM
E.g. My bet is .Net framework a
Usage is higher individual studio than in the overall population
Dang voice to text, *in visual studio
Being able to see the whole list and an API endpoint are stretch goals that may or may not happen in the near term.
Just wanted to give a heads up since we had spoken about it in the past. The PM on our team will be announcing the feature to the community so your thoughts and ideas on the design he proposes would be much appreciated!