Inedo Community Forums Forums
    • Recent
    • Tags
    • Popular
    • Login

    Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

    If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

    Provide a way to document consumers of a nuget package

    Scheduled Pinned Locked Moved Support
    proget
    4 Posts 2 Posters 0 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • ? This user is from outside of this forum
      Guest
      last edited by

      NuGet and ProGet have been huge additions at the company I work for. We have been able to greatly reduce duplicated code by creating shared libraries and using NuGet and ProGet for package management.

      However, as we create more packages and more things consume them, it gets more difficult to know what is consuming what.

      Obviously we can search source control, but that obviously isn't very robust.

      We would like a place we could, perhaps at build time, have a consuming application write data about what NuGet packages it is consuming. We could invent this ourselves obviously, but my first thought was it would be create if this data was available in the ProGet server and viewable when you are looking at a specific package.

      Is something like this an option? I see there is now extension support, but it doesn't appear like the capability to do what I'm talking about is exposed.

      Any thoughts or suggestions would be appreciated.

      Thanks

      Product: ProGet
      Version: 5.0.12

      1 Reply Last reply Reply Quote 0
      • atrippA Offline
        atripp inedo-engineer
        last edited by

        I'm afraid there's no easy answer for this.

        First, keep in mind that dependency resolution is really complicated (see NuGet Docs to get an idea), and it seems some package managers (like npm) even have a nondeterministic (let alone undocumented) algorithm for resolution.

        The only thing that "mostly knows" what packages are actually being used are the client tools themselves (nuget.exe, npm, etc), and you'll really only know what dependencies they've grabbed after you see the packages on disk.

        ProGet has package statistics, which at least shows you which packages are being requested. But nuget.exe puts more information in the requests, so all ProGet "sees" is a request for a package from a address... and often, multiple requests happening in parallel.

        1 Reply Last reply Reply Quote 0
        • ? This user is from outside of this forum
          Guest
          last edited by

          I should have been more clear on what I was asking for. I agree this has to happen from the “client” side. I am mostly just looking for a place the client could put said data and display it, associated with the actual package it is consuming.

          1 Reply Last reply Reply Quote 0
          • atrippA Offline
            atripp inedo-engineer
            last edited by

            I see, that's an interesting idea. It seems like some sort of auto-generated documentation of sorts? I don't know if ProGet is the place for that data, but we don't have a feature to store such doumentation at this time.

            So, maybe you could auto-post it a documentation wiki of sorts and use the "Project URL" property to link to it?

            1 Reply Last reply Reply Quote 0

            Hello! It looks like you're interested in this conversation, but you don't have an account yet.

            Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

            With your input, this post could be even better 💗

            Register Login
            • 1 / 1
            • First post
              Last post
            Inedo Website Home • Support Home • Code of Conduct • Forums Guide • Documentation