Poor quality packages, what you do ?

Topics: Ecosystem
Nov 12, 2012 at 11:30 AM

Hi people im starting to use NuGet and have find in the central repository a lot of tools that i use, i was happy with this, but i have started to seen that several packages doesnt have the necessary dependencies or the correct framework setup.

For example: the package Tamir.SharpSSH has dependency with DiffieHellman and with Org.Mentalis.Security but both of this last packages have only the Assembly inside for net40 wich isnt true, it works for 2.0...

How do you control this things ? 

I can edit the packages in my local repository, that works for me but i think there must be some general solution.

Kind regards.

Enrique

Coordinator
Nov 21, 2012 at 4:50 PM

The best thing to do is to contact the package owners with helpful suggestions to improve the package. Hopefully by educating each other, we can improve the quality of packages in NuGet as a whole.

Nov 28, 2012 at 4:54 PM

Ok, im trying to do that, anyway some packages doesnt even have a contact info in metadata.

Plus the author of the package may not be the author of the library...

I dont know how is the upload of packages to central repository process but maybe if you requirre email verification and someone checks the quality of the packes uploaded can send a email to correct this poor quality packages.

 

Regards.

Dec 3, 2012 at 3:16 AM

I can see the issue a few ways:

1) Authoring mistakes would be better if they didn't happen in the first place. Ideally I would like to see some validation happen on packages to prevent many dependency issues - either at package-build time, or at upload time. However this looks like it takes some time to implement, and likely there would be some limitations discovered in the process of implementing this, such as difficulty of validating multiple version combinations.

2) Unfortunately, there's just no guarantee package owners will update their packages. Packages can be abandoned, or owners can say they just don't want to support the scenario (for whatever reason).

3) There's no license or agreement letting the community or nuget.org to fix abandoned packages that have dependency issues

Personally I think if #3 were fixable that would be kind of exciting, and can go a long way towards mitigating issues 1 and 2!

Ideas along that line - Could package owners opt into an agreement to let the nuget community maintain their package - maybe only in ways which help fix common authoring mistakes? Such as adding missing dependency declarations, or missing framework folders? Or opt into having their package revert to community ownership if they stop maintaining it?

Nov 18, 2013 at 7:44 AM
If a forking-like feature could be offered on nuget.org and related tools then it would go a long way to help the community. It would permit anyone to propose and supply fixes to a package & users to decide to use a particular fork of a package or not. In the ideal scenario, the package project has a public repo that can be forked and the fix can be submitted with a pull request to the owner(s). However, in the case where packages have been abandoned or owner(s) gone dormant, a person interested in making fixes can also publish an interim solution for the community. The download statistics could be used to give some insight into if a particular package fork is getting more popular than the original. I think this could be done without a lot of work by simply using a package Id convention. For example, if a package has an Id of foo and someone publishes a package with Id foo$profile then the latter could appear as related to foo.