WayneBrantley wrote Jan 3 at 2:52 PM

With the new NuGet Package Restore workflow, you no longer check in the dependencies, so this would be a non-issue, right?

Haacked wrote Oct 13 2010 at 11:28 PM

Interesting idea and we'd like to consider this after v1. We mitigated this by compressing nupkg files by default so they don't take as much space. Keep in mind that if we did this, we'd need a way to provide a setting to choose which behavior you wanted.

aL3891 wrote Oct 11 2010 at 12:00 PM

i think the core of the issue is that the nupkg file also contains the binaries of the package causing duplicate data to be checked in.

Perhaps the package installer can remove the actual package content from the .nupkg file and only keep the metadata? it seems probably the the pacage metadata and content(assemblies) are always going to be together anyways.

jpoehls wrote Oct 8 2010 at 5:31 PM

Just to add some numbers to this, a project that only uses the NHibernate.Linq package and NUnit will have a total of 18.6 megs in their /packages folder. That means 9.3 megs are taken by .nupkg files.

That 9.3 megs is a huge difference if you host your code on CodePlex and have a less than stellar upload speed on your internet connection.

I see this as being a pretty big issue for a lot of projects and IMO it should be addressed sooner rather than later.

The only other thing that could be done to help cut space down would be to encourage package makers to now bundle multiple framework versions of their DLLs in a single package. For example, the log4net package includes the DLL for 1.0, 1.1 and 2.0. 99% of the time a project will only require one of those DLLs. Why download them all when they aren't necessary? In log4net's case removing the 1.0 and 1.1 DLLs would save 3.1 megs of space. That's huge.

Haacked wrote Oct 8 2010 at 4:33 PM

Thanks for the feedback Kiliman. I'll talk to the team about this as this item seems to be a popular request. As a piece of history, I originally spec'd it that we'd only store a checksum of the files. But during our prototyping phase, I think it was just easier (coding wise) to just keep the package around and it provided other benefits. But now, I'm not so convinced we made the right choice.

The question now is if we do make this change, do we do it now or in the next version?

Kiliman wrote Oct 8 2010 at 12:51 PM

@Haacked, actually I wasn't thinking of multiple projects in a single solution, but multiple solutions. Why download the package multiple times?

A best practices of version control is to commit all the bits that make up a specific revision. One could argue that as long as you commit the contents of the package (the assemblies, etc.) then you should be fine. That was the philosophy of the original Nu project. We didn't copy the original gem from the gem cache, just the lib folder. Recent versions also include the nuspec file as well.

Now if NuPack has additional content or metadata that should be present independent of the bits used the build the project, then copying the package entirely would make sense. Otherwise, it seems like bloat. You mentioned that it was used to uninstall a package. Can you simply copy the nuspec file? Does the entire package have to be present?

I still think having a local cache would be helpful, especially once NuPack takes off and people are hammering the package server.

Anyway, @ermontgo as for updating a cached package, I imagine NuPack could do like HTTP and query for If-Modified-Since. I think gem is even simpler in that you can't update a package without bumping the version number. That's why you see a bunch of gems for #nuproj like 1.0.1.0.20100905. We were appending the date to differentiate gem versions without changing the "version" of the package (which is the release version).

Sorry to ramble. The current implementation works fine but not as efficient as can be so this can certainly be a V.Future feature.

Kiliman

ermontgo wrote Oct 8 2010 at 6:21 AM

I like Kiliman's solution better than the current implementation; however, I think that some sort of update mechanism would need to be implemented to keep that cache up to date.

jpoehls wrote Oct 7 2010 at 4:49 AM

A checksum would definitely be preferable to storing the nupkg file in my mind. Wanting to keep the nupkg file around for future sharing, etc soundly like an edge case to me. Perhaps that could be supported through a flag when installing packages but I would definitely prefer it be disabled by default.

Haacked wrote Oct 6 2010 at 10:42 PM

@Kiliman, we only download the .nupkg file once per solution. It gets added to a solution level folder and in the case of assemblies, each project references the one copy of the assembly.

I think the original question is around why do we need to keep the nupkg file around in the first place after we've expanded it. If you run the uninstall command, we check to make sure you didn't modify a file before we remove it. The easiest way to do that was to keep the original package around. I don't think the .nuspec file contains the full list of files because it allows for wildcards.

However, we can consider an option where the NuPack.exe expands the nuspec with the list of each file and a CRC checksum and we could use that instead of the nupkg file. Would you prefer that to the current behavior?

One nice thing about keeping packages around is it's easy to then take them, put them all in a network share, and point NuPack to that folder and share packages with others. :)

Kiliman wrote Oct 6 2010 at 6:51 PM

I agree. I think the .nupkg file should be downloaded to a common cache location and only the contents copied to your solution. This is how gems/nu works.

This way the .nupkg file only needs to be downloaded once to add to multiple projects.